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SUMMARY 


This  report  documents  in-house  research  performed  at  the  Air  Force  Human  Resources 
Laboratory  (AFHRL)  into  Decision  Support  Systems  (DSS)  applications  of  Quality  Function 
Deployment  (QFDN  to  improve  the  weapon  systems  requirements  process.  Invoking  Total  Quality 
Management  (TQf  „)  and  Concurrent  Engineering  (CE)  principles,  the  research  identified  tools  and 
techniques  which  if  coupled  with  QFD-like  technology,  would  improve  the  requirements  process. 

TQM  and  CE  are  traced  to  the  requirements  determination  process  and  customer  involvement  in 
that  process.  Since  the  focus  of  this  research  was  to  enhance  the  requirements  process,  a  separate 
section  is  provided  to  define  and  characterize  requirements  and  the  requirements  process  as  well  as 
describe,  in  general  terms,  the  Air  Force  requirements  process.  Having  thus  characterized 
requirements  and  the  process,  the  next  section  of  the  report  presents  various  tools  and  techniques, 
which  can  enhance  the  requirements  determination,  analysis  and  management  functions  within 
weapon  systems  acquisition.  QFD  is  then  described  along  with  a  brief  history  of  the  technique. 

The  purpose  of  the  requirements  characterization  and  the  discussion  of  the  various  tools  and 
techniques  is  to  present  a  framework  within  which  to  define  a  decision  support  environment 
adequate  to  accommodate  and  enhance  the  CE  requirements  process.  Since  QFD  is  seen  as  a 
potential  solution  to  the  challenge,  the  QFD  section  is  intended  to  provide  the  reader  with  sufficient 
background  and  understanding  of  the  QFD  technique  to  realize  the  opportunity  QFD  offers. 
Coupling  aspects  of  QFD  with  decision  support  technology  provides  an  environment  that  offers  a 
potential  solution  to  problems  within  the  requirements  process. 


The  paper  concludes  with  a  summary  of  the  issues  raised  and  findings  determined  through  the 
investigation  of  applying  QFD  to  CE  via  decision  support  technology  for  the  weapon  system 
requirements  process. 
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PREFACE 


The  purpose  of  this  paper  is  to  document  the  work  performed  and  research  findings 
resulting  from  an  in-house  research  effort  investigating  the  application  of  Quality  Function 
Deployment  (QFD),  and  its  matrix-based  graphical  presentation  devices,  to  Concurrent 
Engineering  (CE).  This  investigation  necessarily  examined  the  background  of  QFD  and  CE  as 
well  as  the  Total  Quality  Management  (TQM)  initiative,  the  impetus  for  the  CE  initiative.  The 
investigations  quickly  focused  in  on  the  requirements  process  within  the  weapon  systems 
acquisition  process.  Both  TQM  and  CE  place  heavy  emphasis  on  properly  defining  requirements. 
Thus,  this  paper  describes  TQM  and  CE  from  the  requirements  perspective,  characterizes  the 
requirements  process,  and  defines  a  set  of  tools  and  techniques  to  enhance  the  process.  The  paper 
also  describes  QFD  to  present  the  technique  as  a  potential  solution  to  the  requirements  process 
improvement  effort  called  for  by  TQM  and  CE.  The  investigations  are  built  upon  previous 
research  accomplished  in  the  Decision  Support  Systems  (DSS)  area.  The  resulting  findings  and 
conclusions  comprise  the  conceptual  foundations  for  a  research  program  in  DSS  to  enhance  the 
weapon  systems  requirements  process. 

The  in-house  research  was  not  a  sole  venture,  as  the  author  had  considerable  help.  The 
ideas,  insights,  and  particularly  the  graphics  were  the  resuit  of  a  research  team  from  the  Logistics 
System  Branch:  Captain  Steve  McClendon,  Mr  Brian  Smith,  and  Mr  Matt  Tracy.  Additional 
assistance  came  from  Dr  Michael  Wolfe,  a  Summer  Faculty  Research  member  of  AFHRL  during 
1989,  and  from  fellow  branch  member.  Captain  Michael  Painter. 
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DECISION  SUPPORT  ENVIRONMENT 
FOR 

CONCURRENT  ENGINEERING1  REQUIREMENTS 
I.  INTRODUCTION 

The  purpose  of  this  report  is  to  describe  the  background  and  foundations  of  a  new  research 
effort  within  the  Logistics  and  Human  Factors  Division  of  the  Air  Force  Human  Resources 
Laboratory  (AFHRL).  The  broad  purpose  of  this  research  is  to  improve  the  tools  and  techniques 
used  within  the  weapon  systems  acquisition  process.  Specifically  the  objective  is  to  define, 
develop,  and  demonstrate  computer-based  tools  and  supporting  methodologies  to  enhance 
definition  and  design  efforts  early  in  the  weapon  system  acquisition  process.  How  early? 

Effective  tools  and  methods  are  needed  from  the  time  a  weapon  system  need  is  first  conceptualized 
until  that  system  is  decommissioned.  Since  such  turn-key  systems  are  often  too  large  to  bring  to 
reality,  the  research  effort  discussed  herein  specifically  targets  the  requirements  process  (definition 
and  management)  within  the  weapon  system  acquisition  process. 

This  research  has  evolved  from  several  related  research  efforts.  Within  AFHRL,  this 
research  had  its  beginnings  in  the  Decision  Support  Systems  (DSS),  Integrated  Design  Support 
(EDS),  Unified  Life  Cycle  Engineering  (ULCE),  Reliability,  Availability,  and  Maintainability  in 
Computer-Aided  Design  (RAMCAD)  and  more  recently  the  Concurrent  Engineering  (CE) 
program.2  For  the  most  part,  theoe  efforts  explored  computer-based  solutions  to  different 
functional  aspects  of  the  weapon  system  design  problem.  The  studies  accomplished  and 
technology  developed  under  these  efforts  targeted  the  design  process  within  industry  to  improve 
the  design  and  development  of  industry's  products  in  response  to  government  statements  of  work, 
and  specifications. 

Similarly,  other  DoD  initiatives  and  research  have  targeted  the  design,  manufacture,  and  life 
cycle  support  of  the  weapon  system.  Most  notable  among  these  efforts  are  Computer-Aided 
Acquisition  and  Logistics  Support  (CALS)-related  programs  and,  more  recently,  the  DARPA 
Initiative  in  Concurrent  Engineering  (DICE).  Figure  1  provides  a  brief  overview  of  these  research 
influences. 

Recent  initiatives  in  DoD  to  improve  weapon  system  acquisition,  and  DoD  management  in 
general,  have  introduced  additional  perspectives  to  the  design  and  development  process.  Most 
notably,  the  Total  Quality  Management  (TQM)  initiative,  followed  by  the  Concurrent  Engineering 

Concurrent  Engineering  is  synonymous  with  other  terms  such  as  Concurrent  Design,  Simultaneous 
Engineering,  and  Integrated  Product  Development  (IPD).  This  report  uses  just  the  CE  term. 

2See  Appendix  A  for  complete  list  of  publications  produced  from  the  AFHRL  DSS  effort. 
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initiative,  have  increasingly  emphasized  on  properly  defining  "wha;"  a  system  is  to  do  and  "why"  it 
is  being  built.  In  other  words,  what  are  the  requirements  for  the  system?  What  does  the  customer 
A'ant  and  is  he  satisfied  with  the  product?  Is  the  system  being  properly  uefined  up  front  so  it  is 
built  right  the  first  time? 


CALS  - — _ — RAMCAD  - ULCE  — -  ^  Concurrent  Engineering 
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Figure  1.  Related  Research  Efforts 

Structure  of  the  Paper 


Both  TQM  and  CE  heavily  influenced  the  current  research.  While  it  is  not  the  purpose  of 
this  paper  to  thoroughly  address  TQM,  CE,  and  their  interrelationship,  it  is  important  to  understand 
some  of  this  background,  particularly  with  respect  to  requirements.  This  background  discussion  is 
the  subject  of  Section  II. 

Sections  m  and  IV  present  the  conceptual  basis  for  this  research.  While  Section  HI 
presents  information  influencing  the  research,  Section  IV  presents  actual  findings.  Since  the  effort 
focuses  on  requirements.  Section  III  starts  with  a  discussion  of  requirements  characterizing  the 
activities  and  perspectives  embedded  within  the  requirements  process.  From  this,  the  discussion 
proceeds  into  a  series  of  tools  and  methods,  which  if  embedded  within  a  DSS,  enhance  the 
activities  within  the  requirements  process. 

One  key  theme  of  the  TQM  and  CE  initiatives  is  increased  emphasis  on  methot  ologies  to 
improve  product  and  process  quality.  Some  examples  are  process  improvement  teams,  Taguchi 
experiments,  design  of  experiments,  Statistical  Process  Control,  and  Quality  Function  Deployment 
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(QFD).  TH  examinations  of  QFD  as  a  technique  to  improve  design  within  a  CE  environment 
underscore  the  research  results  presented.  Section  V  provides  a  brief  overview  of  QFD.  Die 
benefits  of  QFD,  as  described  in  Section  V,  include  many  of  the  same  benefits  as  CE.  Coupling 
QFD-based  decision  support  tools  into  a  CE  environment  brings  further  benefits  to  CE.  The 
purpose  of  Section  V  is  therefore  to  familiarize  the  reader  with  QFD  and  some  of  the  inherent 
benefits  of  the  methodology,  particularly  as  these  benefits  present  a  solution  to  the  requirements 
procesc  problem  addressed  in  Sections  III  and  IV. 

Finally,  Section  VI  presents  early  conclusions  derived  from  the  research  along  with  various 
issues  and  observations  raised  during  the  research. 

IL  BACKGROUND3 


The  DoD  adoption  of  TQM  coincides  with  a  reawakening  of  quality  throughout  American 
industry. 

Reawakening  of  American  interest  in  quality  control  can  be  dated 
from  about  1980  when  it  had  become  apparent  that  Japanese 
compames  were  posing  a  serious  competitive  challenge  to  American 
companies  in  one  industry  after  another  [Roberts,  undated]. 

Ironically,  American  industry  is  rediscovering  quality  philosophies  and  quality  techniques 
from  foreign  countries,  most  notably  Japan,  based  on  American  philosophies  and  techniques  The 
most  notable  proponent,  and  an  originator  of  the  philosophies  underlying  the  DoD  TQM  initiative, 
is  Dr.  W.  Edwards  Deming.  In  1980  Deming  was  reintroduced  to  America  in  the  NBC  White 
Paper,  “If  Japan  Can,  Why  Can’t  We?”  [Garuier  and  Naughton,  1988]. 

While  Deming  and  his  philosophies  are  regaining  iame  and  acceptance  in  America,  his 
reputation  in  Japan  is  legendary.  Brought  to  Japan  after  WWII  (as  were  others  inf  hiding  J.  Juran) 
to  assist  in  Japan’s  reconstruction  efforts,  Deming  preached  the  essential  role  of  management  and 
statistics  in  producing  an  organizational  culture  focused  on  quality  [Deming,  1986],  Deming  told 
Japanese  top  management  *his  focus  on  quality  was  essential  to  their  industrial  survival  and  this 
focus  would  bring  industrial  competitiveness  along  with  increased  industrial  market  share. 

Deming  claimed  Japan  would  become  an  industrial  world  leader  if  his  philosophies  were  adopted. 
The  Japanese  listened  and  now,  ironically,  it  is  American  companies  that  travel  to  Japan  to  learn  the 

3So  r.ie  of  this  section  appeared  in  precursor  work.  Hill  1990a  and  featured  in  Hill  1990b.  A  recent,  more 
detailed  examination  of  the  history  of  TQM  is  in  McGovern  1990. 
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secret  of  the  Japanese  industrial  success,  such  as  in  the  DoD-sponsored  Technology  Assessment 
Team  on  Japanese  Manufacturing  Technology  [TAT,  1989].  Deming’s  role  is  signified  in  Japan’s 
much  coveted  Deming  Prize,  Japan’s  highest  honor  for  organizational  quality. 

Why  didn’t  Deming  work  here  in  America?  The  answer  is  he  did.  The  problem  is  that 
after  WWII  American  management  just  quit  listening.  The  massive  war  production  effort  caused 
tremendous  shortages  of  all  goods.  The  U.S.  War  Department  brought  "statistical  control"  into  the 
war  effort  to  deal  with  the  necessarily  large  production  volume  required  to  feed  the  Allied  war- 
machine.  These  statistical  techniques,  classified  during  the  war  effort,  were  developed  by  Walter 
A.  Shewhart  at  Bell  Telephone  Laboratories  during  the  1920s,  and  Shewhart's  concepts  of 
"acceptable  quality  level"  and  "controlled  processes"  had  tremendous  appeal  to  military  production 
personnel.  Deming  was  a  Shewhart  disciple  arid  active  during  the  war  training  producers  in  these 
quality  techniques. 

When  the  war  ended,  industry  had  an  eager  market,  full  of  purchasing  power,  ready  to 
devour  all  the  products  industry  could  provide.  America  had  developed  a  sort  of  “purchasing 
potential”  just  waiting  for  a  release.  Couple  this  market  with  an  intact  industrial  base  (something 
America  had  while  most  of  the  rest  of  the  world  had  to  rebuild),  and  the  ;sult  is  an  environment 
focused  on  meeting  schedules  and  market  demands.  As  J.  Juran  notes,  “What  emerged  was  a 
concept  in  which  upper  management  became  detached  from  the  process  of  managing  for  quality” 
[Juran,  1989],  American  management  simply  lost  interest  in  a  quality  emphasis.  Deming  took 
note  of  this  trend,  and  when  sent  to  Japan,  sought  to  avoid  the  American  situation  by  first 
developing  "management  commitment"  to  quality.  This  key  role  of  management  in  the  quality 
improvement  effort  is  now  fundamental  to  all  of  Deming’s  teachings. 

A  somewhat  similar  occurrence  took  place  in  the  DoD  sector.  As  noted  by  E.  N.  Luttwak, 
America  won  WWII  by  a  strategy  of  "reorganize  and  out-produce."  The  Allied  effort  won  out  over 
the  Axis  powers  due  to  their  (American)  ability  to  out-produce  and  then  numerically  overwhelm  the 
enemy  [Luttwak,  1984],  The  DoD  retained  a  production  emphasis  until  the  mid-1960s.  During 
the  1960s,  US  strategy  moved  away  from  numerical  superiority  to  a  strategy  of  “qualitative 
superiority”  [TAT,  1989].  Under  this  strategy,  military  weapons,  though  fewer  in  number,  are 
technologically  superior,  thereby  offsetting  the  numerical  imbalance.  This  means  that  fewer 
weapons  are  produced.  This  has  caused  a  deemphasis  in  manufacturing  as  the  means  of 
production  [TAT,  1989].  The  lucrative  position  enjoyed  by  American  industry  as  a  whole  after 
WWII  lulled  industry  into  a  false  sense  of  security  about  the  quality  and  competitiveness  of  its 
products. 

Another  factor  to  consider  is  American  research  and  development  (R&D)  emphasis  on  basic 
research.  American  R&D,  through  government  and  commercial  laboratories,  typically  promote 
product  innovation  versus  improvement  of  the  production  processes.  The  American  strategy  is  to 
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demonstrate  the  technology  and  then  let  manufacturing  worry  about  producing  the  product.  This 
approach  pervades  American  culture.  US  companies  spend  about  two  thirds  of  their  R&D  money 
on  new  product  development  while  Japanese  companies  spend  this  same  percentage  on 
manufacturing  process  improvement  [Berger,  1989].  US  policy  for  science  and  technology  has 
basically  ignored  manufacturing  research  focusing  instead  on  basic  research  [Berger,  1989].  So 
while  America  remains  the  world  leader  in  basic  research,  it  has  trouble  “bringing  the  products  to 
market”  and  then  remaining  in  the  market  for  the  long  mn  [Dertouzos,  et  al.,  1989]. 

The  DoD  acquisition  process  possesses  a  similar  lack  of  emphasis  on  manufacturing 
(production)  research  and  issues.  Thus,  all  too  often  weapon  systems  falter  in  the  transition  from 
development  into  efficient  mass  production.  Furthermore,  the  derense  manufacturing  base  is  not 
flexible  enough  to  efficiently  handle  the  short  production  runs  characteristic  of  defense  production 
caused  by  our  qualitative  superiority  strategy.  This  manufacturing  situation  is  a  very  real  concern 
in  the  DoD  where  high  production  rates  are  often  not  possible,  yet  there  is  still  the  need  to  reduce 
production  to  manufacturing  transition  time.  One  DoD  publication  dealing  with  this  issue  is  the 
transition  templates,  DoD  4245.7-M,  ‘Transition  From  Development  to  Production.” 

Since  WWH,  foreign  countries,  most  notably  Japan,  have  quietly  pursued  manufacturing 
excellence  predicated  on  commitment  to  quality  in  their  products  and  their  processes.  The  end 
result  is  a  “crisis”  in  American  productivity  and  international  competitiveness  [Dertouzos,  et  al., 
1989].  Whether  the  perceived  crisis  is  real  is  the  subject  of  much  debate  [Berger,  et  al.,  1989; 
Dertouzos,  et  al.,  1989;  Reich,  1989].  The  crisis  concerns  the  military  because  the  military  is  one 
of  American  industry's  more  valuable  customers. 

Government  is  at  once  the  biggest  customer  and  the  biggest  supplier 
in  America  [Perry,  1986]. 

Today,  the  US  Department  of  Defense  is  a  major  customer  of  more 
than  215  industries,  purchasing  products  that  range  from  office 
supplies  and  clothing  to  high-performance  aircraft.  It  is  often 
difficult  to  draw  a  clear-cut  distinction  between  the  US  defense 
industrial  base  and  the  US  commercial  manufacturing  economy 
across  this  spectrum.  For  this  reason,  the  department  has  a  major 
stake  in  the  state  of  the  nation’s  competitive  posture  [McCormack, 

1989]. 

Industrial  competitiveness  affects  the  American  industrial  base  and  the  ability  of  this 
industrial  base  to  meet  weapon  system  development  and  production  demands,  particularly  in 
wartime.  An  inadequate  industrial  base  can  lead  to  military  disaster  when  industry  fails  to  respond 
to  wartime  mobilization  needs  [Berry,  1988].  In  addition,  the  DoD  faces  contracting  with  foreign- 
owned  companies.  An  article  by  Lawrence  C.  Grossman  [1989]  addresses  this  specific  issue: 
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Foreign  takeovers  present  a  real  concern  to  DoD.  That  is  foreign 
owned  companies  involved  in  sensitive  contracts. 

Many  defense  analysts  argue  that  foreign  takeovers  are  accelerating 
the  erosion  of  the  U.S.  defense  industrial  base,  placing  national 
security  in  jeopardy. 


The  DoD's  response  to  the  decline  of  American  quality,  the  lack  of  emphasis  c 
manufacturing,  and  the  erosion  of  industrial  competitiveness,  is  TQM. 

The  need  for  a  TQM  strategy  in  DoD  stems  from  economic  events  at 
the  national  level.  First,  the  US  is  being  faced  with  an  accelerating 
balance  of  trade  deficit  that  affects  most  major  industries.  Second, 

US  industry  and  the  economy  as  a  whole  have  suffered  from 
lagging  productivity  improvement.  Finally,  the  performance  and 
reputation  of  US  goods  and  services  has  decreased  simultaneously 
[Motley,  1989]. 

Naturally,  the  DoD  acquisition  community  is  the  focus  of  TQM  activity.  The  acquisition 
community  is  the  DoD  interface  to  the  industrial  base.  In  fact,  Robert  B.  Costello  said,  “TQM  is 
our  way-of-life  approach  to  conducting  tne  defense  acquisition  process”  [Costello,  1989].  But  not 
only  is  the  acquisition  community  the  industrial  base  interface,  the  acquisition  community  has  long 
been  the  target  of  scrutiny,  and  some  rather  scathing  texts  have  been  written  on  the  subject  such  as 
Luttwak’s  [1984].  In  particular,  the  need  is  for  the  acquisition  community  to  streamline 
operations,  reduce  bureaucratic  overhead,  and  better  produce  weapon  systems  for  the  DoD  versus 
the  individual  Service  preference. 


Concurrent  Engineering 


Under  the  TQM  umbrella,  DoD  tasked  The  Institute  for  Defense  Analyses  (IDA)  to  examine 
claims  that  CE  was  a  key  technique  to  improve  product  quality  while  lowering  product 
development  time  [Costello,  1989].  The  IDA  study  strongly  supported  the  claim  and 
recommended  DoD  adoption  of  CE  as  a  critical  technology  for  meeting  TQM  goals  and  objectives. 
On  Mar  9, 1989,  Under  Secretary  of  Defense  for  Acquisition,  Robert  B.  Costello  issued  a 
memorandum  "Concurrent  Engineering  -  A  Total  Quality  Management  Process."  With  the 
issuance  of  this  memorandum,  CE  became  a  critical  technology  of  the  DoD  TQM  initiative 
[Costello,  1989].  The  IDA  Report,  “The  Role  of  Concurrent  Engineering  in  Weapon  Systems 
Acquisition”  stated  CE  could  “contribute  to  our  Total  Quality  Management  (TQM)  objectives  of 
reduced  cost,  reduced  time,  and  improved  quality”  [Winner,  et  al.,  1988]. 
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The  DoD  adopted  CE  and  the  now  accepted  definition  of  CE  put  forth  by  IDA  is: 

Concurrent  engineering  is  a  systematic  approach  to  the  integrated, 
concurrent  design  of  products  and  their  related  processes,  including 
manufacture  and  support.  This  approach  is  intended  to  cause  the 
developers,  from  the  outset,  to  consider  all  elements  of  the  product 
life  cycle  from  conception  through  disposal,  including  quality,  cost, 
schedule,  and  user  requirements  [Winner,  et  al.,  1988]. 

But  some  might  claim,  and  have  a  good  argument,  that  CE  is  merely  systems  engineering 
(SE)  by  a  different  name.  The  Defense  Systems  Management  College  definition  for  systems 
engineering  is: 

Systems  Engineering  is  the  application  of  scientific  and  engineering 
efforts  to  (a)  transform  an  operational  need  into  a  description  of 
system  performance  parameters  and  a  system  configuration  through 
the  use  of  an  iterative  process  of  definition,  synthesis,  analysis, 
design,  test,  and  evaluation;  (b)  integrate  related  technical  parameters 
and  ensure  compatibility  of  all  physical,  functional  and  program 
interfaces  in  a  manner  that  optimizes  the  total  system  definition  and 
design;  (c)  integrate  reliability,  maintainability,  safety,  survivability, 
human,  and  other  such  factors  into  the  total  engineering  effort  to 
meet  cost,  schedule,  and  technical  performance  objectives. 

As  discussed  in  Wiskerchen  and  Pittman  [1989],  systems  engineering  has  been  a  very 
successful  technique  in  past  DoD  development  efforts  dealing  with  large,  complex  systems. 
Successes  noted  include  the  Explorer  I  satellite  launch  and  the  landing  of  a  man  on  the  moon. 
There  have,  however,  been  notable  failures  as  well,  such  as  the  Sergeant  York  air  defense  gun  and 
the  space  shuttle  [  Wiskerchen  and  Pittman,  1989]. 

The  classic  systems  engineering  model  as  depicted  in  Figure  2  doesn’t  appear  robust 
enough  to  handle  the  design,  development,  and  acquisition  of  modem  weapon  systems.  The 
model  is  simply  too  restrictive.  Modem  weapon  systems  are  too  complex,  satisfy  too  many 
functional  requirements,  and  take  too  long  to  design,  acquire,  and  field  to  follow  what  is  perceived 
as  a  sequential,  management-review  oriented  approach  to  weapon  system  design.  A  more  robust 
design  methodology  is  required,  one  dynamic  enough  to  handle  modem  weapon  systems  design 
and  development  [  Wiskerchen  and  Pittman,  1989].  Naturally  this  view  of  the  SE  model  might 
cause  discussion.  After  all  the  model  is  really  just  a  framework  adapted  to  the  particular 
implementation,  and  there  is  no  reason  why  iteration  can  not  be  accommodated.  The  point  being 
made  here  is  that  the  SE  model  might  promote  implementations  not  robust  enough  for  modem 
design  and  development  efforts. 

The  CE  model  (Figure  3)  represents  a  subtle  change  to  systems  engineering.  Rather  than 
the  sequential,  management-review  oriented  perspective  of  the  previous  model,  CE  provides 
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concurrent  product  and  process  development,  complete  with  the  iterations  inherently  present  in 
more  complex  design  situations. 


CE  is  basically  systems  engineering  except  systems  engineering 
focused  on  the  product,  not  the  process.  Good  companies  have 
been  bringing  people  together  to  solve  problems  for  years.  CE  is 
just  the  application  of  systems  engineering  principles  and  of 
management  approaches. 


Integrated  engineering  of  products  and  their  associated  production 
and  logistics  processes  with  the  objective  of  providing  a  product  and 
production  process  that  is  robust  during  manufacturing  and 
customer  use.  The  engineering  process  integration  begins  at 
requirements  definition  and  continues  through  production  operations 
and  the  products  life  cycle  [Diaz,  1990]. 

Thus,  as  pointed  out  by  Hutchison  and  Hoffman  [1990],  the  goal  of  CE  is  "to  achieve 
mutual  optimization  of  a  product's  critical  characteristics  and  its  related  processes."  Computer  tool 
vendors  have  made  great  strides  towards  optimization  of  a  product's  critical  characteristics.  There 
are  multitudes  of  computer-based  tools  to  help  effectively  and  efficiently  design  a  product  and  the 
manufacturing  processes  to  build  in  the  product's  characteristics.  For  example,  Computer-Aided 
Design  (CAD)  tools  now  provide  for  on-line  reliability  and  testability  analyses  while  the  design  is 
still  in  the  drawing  stage.  Other  tools  provide  capabilities  such  as  assessments  of  the  pnoducibility 
of  mechanical  parts  prior  to  generation  of  the  numerical  code  controlling  the  machining  process 
[Mayer,  et  al.,  1990].  In  fact,  it  has  been  pointed  out  that  CE  is  nothing  more  than  the  original  SE 
process;  it  is  just  that  computer  technology  has  enabled  designers  to  handle  the  complexity  and  data 
requirements  associated  with  the  weapon  system  design  process  [Tetmeyer,  1990].  But  the 
coming  of  age  of  computer  tools  is  just  one  aspect  of  CE  differing  from  SE. 


Sequential  Engineering 


Requirement 


Product 

Development 


Product 

Prototype 


Process 

Development 


Figure  2:  Systems  Engineering  Model 
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Concurrent  Engineering 


Product  Development 


Requirement 


Process  Development 
_ Prototype _ 


Figure  3:  Concurrent  Engineering  Model 


So  while  CE  tool  development,  such  as  the  above  examples,  has  garnered  the  largest 
amount  of  support  to  date,  there  are  actually  at  least  eight  dimensions  to  CE.4  These  are: 

•  top-down  systems  engineering  approach, 

•  cross-functional  development  teams, 

•  interdisciplinary  work  groups, 

•  quality  engineering  methods, 

•  integrated  computer-aided  engineering  environments, 

•  focus  on  the  customer  and  customer  requirements, 

•  improved  design  processes, 

•  improved  management  of  the  design  process. 


Where  CE  really  departs  from  systems  engineering  is  that  CE  recognizes  the  important  role 
of  the  designer,  the  design  team,  as  well  as  the  computer  tools  necessary  to  realize  the  system 
design. 


As  practiced  in  Japan,  it  (concurrent  design  or  concurrent 
engineering)  is  a  group  process  where  members  of  the  group 
represent  interests  spanning  the  life  cycle  of  the  product  [TAT, 

1989]. 

Applying  CE  concepts  and  philosophies  to  the  government  side  of  the  weapon  system 
acquisition  equation  is  just  as  critical  as  DoD  promoting  adoption  of  CE  by  defense  contractors.  In 
one  sense,  the  DoD  acquisition  community’s  customer  is  industry.  The  DoD  products  are  the 
statements  of  need,  statements  of  work,  requests  for  proposal,  etc.  that  form  the  basis  for  the 
development  effort.  The  better  we  in  the  DoD  produce  our  products,  the  more  we  satisfy  our 
customer,  industry.  In  turn,  the  DoD  is  industry’s  customer.  Industry  returns  to  DoD  the  systems 


4These  dimensions  are  drawn  in  part  from  the  work  of  Mayer,  et  al.,  1990. 

9 


developed  as  part  of  the  contracted  efforts.  It  is  a  chain  of  interdependencies  only  as  strong  as  the 
weakest  link  in  the  chain. 

The  CE  effort,  as  well  as  the  TQM  effort,  within  the  government  is  large  and  has  to  be 
worked  by  many  people  at  different  levels  of  responsibility  to  make  the  effort  work.  For  instance, 
consider  the  following  comment  by  Secretary  of  Defense  Cheney  in  Kitfield  [1989]: 

At  the  heart  of  our  (DoD)  effort  to  reform  the  management  of  the 
Pentagon  lies  the  challenge  of  persuading  members  of  Congress  that 
they  have  imposed  an  awful  lot  of  limitations  and  restrictions  on  the 
department  that  make  it  very  difficult  to  us  to  do  our  business. 

The  limitations  and  restrictions  within  the  acquisition  process  can  only  be  changed  at  the 
highest  levels  of  DoD  acquisition  management  Even  changes  in  the  requirements  process  have 
aspects  properly  considered  at  the  highest  level.  As  indicated  in  the  Packard  Commission  Report, 
A  Formula  for  Action,  blending  requirements  from  user  and  technical  aspects  is  a  very  difficult 
process  requiring  “a  blend  of  diverse  backgrounds  and  perspectives  that,  because  the  pressures  for 
goldplating  can  be  so  great,  must  be  achieved  at  a  very  high  level  in  DoD”  [Perry,  1986]. 

The  necessary  changes  at  the  high  levels  of  DoD  management  are  a  common  subject  in  DoD 
acquisition  literature.  The  DSMC  publication,  Program  Manager,  contains  a  column  whose  subject 
is  the  current  status  of  acquisition  improvement.  Reports,  articles,  even  books,  such  as  those  by 
Kent  [1989],  Ferguson  [1990],  and  Record  [1988]  examine  possible  solutions  to  these  DoD- level 
issues.  Regardless  of  the  macro-level  structure  changes,  there  will  always  remain  the  worker-level 
requirement  to  function  within  that  structure  to  define,  develop,  and  deliver  weapon  systems  into 
the  DoD  inventory.  Thus,  while  TQM  and  CE  have  objectives  at  the  macro-level  structure  of 
weapon  systems  acquisition,  both  initiatives  bring  influence  into  the  worker-level,  the  micro-level, 
aspect  of  weapon  systems  acquisition. 

From  an  acquisition  standpoint  (and  manufacturing  in  general),  TQM  “starts  with  the 
correct  definition  of  user  requirements”  [Strickland,  1989].  While  aspects  of  the  weapon  systems 
requirements  process  are  changed  at  high  levels,  the  fundamental  need  for  a  new  system  and  the 
requirements  that  characterize  that  system  are  in  fact  handled  at  a  much  lower  level  in  the  DoD 
management  bureaucracy.  CE  is  “characterized  by  a  focus  on  customer  requirements”  [Winner,  et 
al.,  1988].  This  is  one  of  the  strongest  links  between  TQM  and  CE.  The  requirements  process  is 
so  important  to  concurrent  engineering  and  system  acquisition  in  general,  that  the  focus  of  this 
particular  research  effort  is  on  improving  that  process. 

In  DoD  acquisition,  the  ultimate  customer  is  the  system  user,  the  soldier  in  the  field.  If  a 
system  is  designed  and  produced  to  meet  every  specification  perfectly,  it  is  still  not  a  “quality” 
system  unless  the  system  is  usable  by  the  soldier  in  the  field.  Thus,  the  acquisition  community 
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marches  to  a  dual  concept  of  quality.  Quality  in  Fact  examines  whether  the  system  is  built 
correctly.  Quality  in  Perception  examines  whether  the  user  likes  the  system  and  whether  it  meets 
his  needs.5 


The  combat  command’s  requirements  are  the  ‘voice  of  the  customer’ 
to  which  all  development  and  supporting  agencies  must  respond. 

The  USAF  customer  has  spoken  and  the  words  are  Combat 
Capability  [Goodell,  1988]. 

While  referring  to  the  USAF  R&M  2000  process,  Brigadier  General  F.  Goodell, 
USAF/LE-RD,6  captured  the  essence  of  TQM  and  CE;  requirements  feed  the  entire  acquisition 
process. 

How  can  the  process  be  improved?  Improved  communication  with  the  user  is  one  way. 
Improved  communication  among  the  design  team  members  is  another.  This  requires  bringing 
together  as  a  team,  personnel  from  the  various  functional  areas  to  address  critical  life  cycle  issues 
early  in  the  design  process,  while  at  'he  same  time  facilitating  communication  among  the  team 
members.  The  SE  process  must  also  be  improved  by  CE  concepts  to  increase  discipline  in  the 
requirements  definition  process  and  focus  design  efforts  on  satisfying  the  customer  requirements. 
The  tools  and  techniques  to  define,  analyze,  and  manage  requirements  for  a  weapon  system  must 
be  adequate  and  integrated  to  promote  efficiency  within  the  requirements  process.  Adequate  tools 
must  fit  into  and  enhance  the  requirements  process.  The  next  sections  describe  the  requirements 
process  from  a  somewhat  abstract  point  of  view  and  then  describe  a  set  of  tools  and  techniques  that 
enhance  the  process.  The  purpose  is  two-fold.  First,  an  adequate  decision  support  environment 
must  fit  the  described  environment,  and  second,  the  components  of  that  support  environment  must 
enhance  the  environment. 


III.  REQUIREMENTS  PROCESS 

All  systems  are  designed  and  built  to  satisfy  a  set  of  requirements.  These  requirements 
arise  with  the  identification  of  a  weapon  system  need  to  meet  an  operational  threat  scenario.  The 
process  by  which  these  needs  are  determined  and  defined  is  the  critical  first  step  in  the  acquisition 
process.  Since  requirements  are  the  foundation  for  effective  systems  development,  a  goal  of  CE  is 
to  improve  the  requirements  trade-off  process  while  moving  the  process  into  the  earliest  stages  of 
the  acquisition.  Thus,  better  methodologies  and  supporting  computer  tools  are  necessary  to 


5These  concepts  of  Quality  in  Fact  and  Quality  in  Perception  come  from  Townsend  and  Townsend’s  1986 
book,  Commit  to  Quality. 

6USAF/LE-RD  is  now  designated  SAF/AQXE. 
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enhance  the  requirements  environment  Any  attempt  to  build  tools  and  methodologies  must  be 
preceded  by  developing  an  understanding  of  the  current  environment 

What  exactly  is  a  weapon  system  requirement?  From  the  Air  Force  Institute  of  Technology 
(AFIT)  [AMT,  1990],  a  requirement  is  "the  need  or  demand  for  personnel,  equipment,  facilities, 
other  resources,  or  services,  by  specific  quantities  for  specific  periods  of  time  or  at  a  specified 
time."  Two  related,  more  specific  definitions  also  come  from  AFIT.  First,  a  required  operational 
characteristic  is  "a  system  parameter  (or  set  of)  that  are  primary  indicators  of  the  system’s 
capability  to  be  employed  to  perform  the  required  mission  functions,  and  to  be  supported."  A 
required  technical  characteristic  is  "a  system  parameter  (or  set  of)  selected  as  primary  indicators  for 
achievement  of  engineering  goals.  These  may  not  be  direct  measures  of,  but  should  always  relate 
to  the  system’s  capability  to  perform  the  required  mission  functions,  and  to  be  supported."  [AFIT, 
1990]. 

The  AFIT  set  of  definitions  imply  a  specified  system,  parameterized  and  quantified. 
Further,  this  set  implies  a  somewhat  static  environment  in  which  the  requirements  are  set  and 
remain  relatively  stable  from  then  on.  Not  until  full-scale  development  will  such  a  set  of 
requirements  become  available  [Ferguson  and  Hertz;  1990].  The  Pymatuning  study  on  CE  labeled 
this  characteristic  of  requirements  as  a  "lack  of  clarity  in  the  definition  of  the  requirements"  citing 
the  characteristic  as  one  of  two  inhibitors  within  the  requirements  specification  process.7  This 
inhibitor  "results  in  an  inability  to  define  real  requirements  in  the  early  concept  and  design 
definition  phases  of  a  program."  Part  of  this  inability  stems  from  the  inability  to  adequately 
perform  trade-off  studies  among  competing  requirements  [Pymatuning,  1988]. 

While  the  AFIT  definitions  provide  a  necessarily  general  definition  followed  by  two  more 
specific,  supporting  definitions,  a  definition  by  itself  fails  to  explain  the  more  abstract  elements  of 
the  requirements  process  and  environment.  The  following  discussion  seeks  to  better  characterize 
requirements. 

The  terms  requirements  and  need  seem  synonymous.  In  fact,  the  dictionary  supports  this. 
A  need  is  "something  useful,  required"  while  a  requirement  is  "something  needed;  a  necessity." 
Must  there  be  a  distinction?  Our  research  indicates  there  must  be  a  difference,  albeit  a  subtle 
difference.  Weapon  systems  are  developed  to  meet  operational  threats.  As  stated  in  Section  II,  the 
TQM  and  CE  initiatives  must  be  addressed  at  various  levels  in  DoD.  Operational  threats  are 
derived  from  the  National  Security  Strategy  of  the  United  States.  One  can  not  get  much  higher  in 
the  DoD.  As  this  strategy  permeates  through  the  DoD,  operational  planners  eventually  uncover  a 
weapon  system  "need"  to  counter  an  operational  scenario.  This  need  is  met  by  existing 


7 _ 

'The  second  inhibitor  listed  in  the  Pymatuning  report  was  a  lack  of  a  realistic  process  for  generating 
requirements,  a  topic  addressed  by  Ferguson  and  Hertz,  1990. 

12 


capabilities,  tactic  changes  employing  existing  capabilities,  or  the  development  and  acquisition  of 
new  systems  (modified  or  newly  developed). 

For  acquisition  efforts,  the  need  undergoes  a  sequence  of  redefinitions  and  transformations 
referred  to  as  product  design  and  development  This  sequence  produces  an  increasingly  exact  set 
of  limiting  conditions  (requirements)  on  the  needs  that  must  be  met.  The  end  use  system  should 
satisfy  the  final  set  of  requirements  defined  to  meet  the  previously  defined  operational  need. 

The  above  definitions  of  need  and  requirement  establish  a  clearer  delineation  between  a 
need  and  the  requirements  generated  to  satisfy  that  need.  Having  delineated  the  two  terms,  we  can 
characterize  the  overall  requirements  process  as  having  three  perspectives: 

•  functional  perspective, 

•  hierarchical  perspective,  and 

•  bureaucratic  perspective. 

Within  the  above  perspectives  are  three  aspects  (or  phases)  of  requirements.  These  are: 

•  definition  of  requirements, 

•  analysis  of  requirements,  and 

•  management  of  requirements. 

At  any  point  in  time,  personnel  involved  in  the  requirements  process  operate  in  a  single 
dimension  of  the  process.  We  define  dimension  to  mean  operating  in  a  particular  perspective  while 
working  on  a  particular  aspect  of  the  requirements.  While  that  person  will  not  make  a  conscious 
decision  to  work  that  particular  dimension  (perspective  +  aspect)  of  the  requirements, 
understanding  this  dynamic  interaction  among  perspectives  and  aspects  is  quite  useful,  not  just  an 
academic  exercise.  One  immediate  use  is  to  develop  DSS  technology.  To  build  a  DSS  that 
effectively  enhances  the  overall  requirements  process  and  environment  requires  that  the  DSS 
accommodate  this  dynamic  interaction.  Thus  if  we  can  build  DSS  technology  to  accommodate  any 
of  the  possible  dimensions  of  the  requirements  process,  that  DSS  can  enhance  all  phases  of  that 
requirements  process. 


Perspectives  of  Requirements 

A  requirement  perspective  addresses  how  to  view  the  set  of  requirements.  One  might  say  a 
design  is  just  a  design  and  a  "perspective"  is  just  a  useless  abstract  concept.  However,  how  one 
examines  that  design  truly  is  dependent  upon  the  job  at  hand  (the  person's  position  plus  current 
task).  This  is  their  perspective.  The  ability  to  examine  design  data  (manually  or  computer- 
assisted)  in  a  manner  conducive  to  successfully  completing  the  job  is  essential. 
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Bureaucratic  Perspective 

The  nature  of  requirements  necessarily  changes  based  upon  the  level  of  management 
review.  For  instance,  during  full-scale  development,  a  program  manager  is  concerned  with 
functional  requirements  for  the  system.  At  the  same  time,  however,  Program  Element  Monitors 
(PEMs)  at  the  Headquarters  level  are  less  technically  inclined.  Thus,  requirements  tend  to 
aggregate  and  become  more  general  as  those  requirements  are  reviewed  up  the  management  chain. 

It  is  this  perspective  that  causes  improvements  in  the  requirements  process  to  require  efforts  at  all 
levels  of  the  DoD  acquisition  management  chain,  since  all  levels  are  involved  in  the  requirements 
process.  The  bottom  line  is  that  the  level  of  detail,  or  level  of  aggregation,  with  which  one  views  a 
set  of  requirements  depends  upon  the  management  level  or  management  role  of  the  individual. 

Functional  Perspective 

Any  weapon  system  is  a  composite  of  many  items  (e.g.,  engines,  airframes,  avionics,  etc.) 
and  related  supporting  resources  (e.g.,  training  pipeline,  logistics  support,  etc.).  Each  piece  of  this 
complex  weapon  system  has  characteristics,  which  in  a  sense  comprise  the  full  suite  of  the  weapon 
system  requirements.  At  any  instance,  this  full  suite  of  requirements  might  be  examined  by  one 
particular  functional  specialty.  Thus  requirements  have  various  functional  perspectives  embedded 
within  the  full  suite  designed  to  satisfy  this  functional  perspective  need. 

For  example,  the  classic  pre-CE  analogy  of  design  was  an  environment  of  "over-the-wall" 
design  handoffs.  Here,  design  engineers  did  their  job  relatively  isolated  from  considering  other 
functional  areas.  The  designers  created  the  design  and  handed  the  design  to  manufacturing 
personnel,  for  example.  Lack  of  communication  was  "the  wall"  over  which  the  designs  flowed. 

In  a  CE  environment,  with  its  multifunctional  teams,  designs  are  examined  by  all  team  members 
concurrently.  Thus,  a  design  engineer,  maintainability  engineer,  and  logistics  support  analyst  may 
view  a  design  with  each  trying  to  improve  the  design  from  their  functional  concern  but  cognizant  of 
the  other  person's  concerns.  Each  takes  a  different  "perspective"  of  the  same  design.  The 
aggregation  of  each  perspective's  input  comprises  the  full  design. 

Hierarchical  Perspective 

The  hierarchical  perspective  addresses  the  evolving  nature  of  requirements  in  terms  of  level 
of  design  detail.  Initially,  system  requirements  are  very  broad  system-level  requirements 
emanating  from  operational  needs  (e.g..  Statement  of  Operational  Need  (SON),  and  Statement  of 
Operational  Requirements  Document  (SORD),  etc. ),  system  level  specifications  (e.g.,  system 
specification.  Type  A),  through  detailed  design  specifications  (e.g..  Type  C). 

In  a  very  real  sense,  these  levels  of  design  detail  represent  an  evolution  of  the  requirements 
(via  a  hierarchical  decomposition  process  such  as  implied  by  the  systems  engineering  approach) 
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incorporating  increasingly  restrictive  technical  characteristics.8  Therefore,  at  any  point  during  the 
design  process  one  may  wish  to  view  requirements  at  a  particular  level  of  design.  Breaking 
requirements  into  lower  levels  of  detail  facilitates  the  engineering  task. 

For  example,  reliability  engineers  may  examine  a  system  design  at  a  functional  block  level, 
followed  by  subsystem  high-level  design,  or  at  the  board  or  component  level.  Exactly  how  the 
design  is  viewed  depends  upon  the  level  of  design  detail  achieved;  it  depends  upon  how  far  the 
design  decomposition  has  progressed.  Furthermore,  a  decision  at  one  particular  level  of  design 
may  affect  decisions  made  at  other  levels  of  design.  The  engineer  needs  the  capability  to  move 
between  design  levels. 


A  requirement  is  defined,  it  is  analyzed/modified,  and  it  is  managed.  We  define  these  as 
the  three  aspects  of  requirements.  Techniques  (manual  or  computer-assisted)  that  aid  in 
accomplishing  tasks  in  these  aspects  save  time,  provide  more  complete  and  thorough  processing, 
and  ensure  consistency  among  the  requirements.  The  three  aspects  defined  are  similar  to  those 
posed  by  Ferguson  and  Hertz  [1990]  in  relationship  to  defining  the  term  requirement: 

The  definition  of  requirement  depends  on  where  one  is  in  the 
requirements  planning  process.  Requirements  planning  begins  with 
an  examination  of  the  operational  need.  It  continues  as  weapon 
system  alternatives  are  evaluated  according  to  how  well  they  allow 
us  to  fulfill  operational  requirements.  Finally,  requirements 
planning  makes  trades  in  performance,  cost,  and  schedule  to 
determine  the  optimum  system  performance. 


Requirements  are  defined  as  those  efforts  focused  on  determining  operational  behaviors  of 
the  final,  fielded  system.  The  personnel  initially  involved  in  such  efforts  are  concerned  with 
system  capabilities  to  meet  operational  threats  and  mission  needs.  The  analyst/planner  defines 
operational  concepts  to  meet  operational  needs.  Using  knowledge  of  current  system  capabilities 
the  analyst/planner  correlates  operational  needs  to  existing  capabilities.  This  correlation  activity 
enables  the  planner/analyst  to  determine  voids  in  current  capabilities  thereby  defining  requirements 
for  new  development  or  current  system  modification.  This  need  determination  is  the  earliest 
requirements  determination  effort. 

Restrictive  in  the  sense  that  as  design  detail  is  added,  the  set  of  feasible  designs  is  reduced. 
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As  this  need  undergoes  iterations  of  redefinition  and  transformations,  the  need  generates  a 
set  (or  sequence  of  sets)  of  requirements  defining  the  weapon  system.  During  each  iteration,  input 
is  in  the  form  of  needs  and  previously  defined  requirements.  Personnel  involved  take  this  input 
and  determine  the  requirements  for  their  particular  perspective.  Thus  a  supporting  discipline,  such 
as  manpower,  personnel,  and  training  (MPT),  might  examine  current  design  input  and  determine  a 
set  of  corresponding  requirements  reflecting  MPT  concerns  appropriate  for  the  current  level  of 
design  detail. 

Requirements  Analysis 

While  the  definitional  aspect  requires  the  listing  of  requirements,  the  analytical  aspect 
provides  the  "reality  check."  A  weapon  system  design  is  actually  a  sub-optimized  set  of 
requirements  from  all  affected  functional  disciplines.  They  are  sub-optimized  in  the  sense  that  each 
functional  requirement  might  be  less  than  optimum  due  to  its  effect  on  the  remainder  of  the  system; 
it  is  weakened  for  the  strength  of  the  overall  system.  It  is  this  analysis,  or  tradeoff  process  that  is 
essential  to  successful  development,  and  the  acquisition  of  weapon  systems  within  cost,  schedule, 
and  performance  constraints. 

Requirements  analysis,  in  this  context,  is  defined  as  the  set  of  activities  involving  cost, 
schedule,  and  performance  trade-offs  that  attempt  to  meet  the  operational  needs  of  the  new  system. 
Real-world  resouice  constraints  prevent  100%  satisfaction  of  all  system  needs  or  requirements. 
This  necessitates  rational  tradeoffs  to  support  the  most  critical  characteristics  of  the  system. 
Additionally,  requirements  from  supporting  functional  disciplines  are  incorporated  into  the  effort. 
Such  supporting  disciplines  include  reliability,  maintainability,  logistics  support,  manpower, 
personnel,  and  training,  to  name  a  few. 

Requirements  Management 

The  last  aspect  supported  is  requirements  management,  which  means  the  e  activities 
associated  with  maintaining  the  integrity  of  the  system  requirements  as  the  requirements  evolve 
over  time.  Requirements  management  deals  with  those  actions  necessary  to  ensure  management 
oversight  is  properly  applied  to  the  program  to  best  correspond  to  the  relative  priori i;  and  risk 
associated  with  each  system  requirement  Among  the  issues  affecting  requirements  management 
are: 

•  audit  trail  of  requirement  changes, 

•  rationale  for  determining/modifying  requirements, 

•  impacts  on  and  interrelationships  between  requirements, 

•  impacts  to  cost  and  schedule  due  to  status  of  requirements  satisfaction, 

•  consistency  of  requirements  throughout  the  acquisition  effort,  and 

•  systems  requirements  impact  on  the  other  potential/fielded  systems. 
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In  DoD,  the  combat  command’s  needs  for  a  system  ultimately  determine  their  level  of 
satisfaction  with  the  fielded  system.  These  are  the  customer  requirements  for  the  weapon  system. 
However,  systems  are  built  to  system  design  requirements  derived  from  the  customer  requirements 
(the  combat  command’s  needs).  Ho«’  wcU  a  system  satisfies  the  system  requirements  is  indicative 
of  combat  command  satisfaction  with  the  system  only  to  the  extent  the  original  needs  were 
accurately  translated  into  appropriate  system  requirements. 

The  vehicle  for  defining  a  need  and  ttie  associated  operational  requirements  to  meet  that 
need,  are  the  Statement  of  Operational  Need,  the  SON.  For  Joint  Service  efforts  the  Joint  Service 
Operational  Requirements  (JSOIi)  is  the  requirements  document.  The  process  in  place  for  these 
documents  is  found  in  Air  Force  Regulation  57-1.  The  SON  establishes  the  foundation  for  the 
acquisition  effort.  The  primary  purpose  of  the  SON  is  to  describe  the  need  in  opeiational  terms, 
relating  u.e  need  to  planned  operations  and  support  concepts.  Its  principal  uses  are  to: 

( 1 )  define  an  operational  need, 

(2)  obtain  official  validation,  and 

(3)  furnish  preliminary  program  guidance. 

There  are  also  supporting  documents  required  within  the  defined  process.  The  System 
Operational  Requirements  Document  (SORD)  refines  the  elements  of  the  SON  explaining  how  to 
operate,  employ,  deploy,  and  support  the  proposed  system.  It  details  the  operational  requirements 
of  the  system  supported  by  Program  Objective  Memorandum  (POM)  funding.  Together  vith  the 
SON,  ‘he  SORD  provides  initial  program  guidance  in  preparing  Requests  for  Proposals  (RFPs), 
requirements  for  testing,  warranties,  program  management,  and  program  planning.  Additionally, 
AFR  57-1  requires  SORD  updates  prior  to  each  major  program  mi1  es tone,  with  changes  tracked  in 
the  Requirements  Correlation  Matrix  (RCM).  These  updates  provide  additions  quantitative  and 
qualitative  factors  on  the  performance  and  support  characteristics  for  the  system. 

As  implied  above,  the  RCM  is  used  to  track  changes  to  the  user  requirements  (as  contained 
in  the  SON  and  SORD)  as  those  requirements  evolve  over  the  life  of  the  program.  An  additional 
purpose  is  to  provide  a  means  to  easily  compare  how  well  requirements  correlate  to  specifications 
and  test  criteria.  The  RCM  is  discussed  again  in  Section  V  as  a  tool/technique  to  enhance  the 
requirements  process. 


9Thc  details  on  the  SON,  SORD,  DSRD,  and  the  involved  commands,  are  paraphrased  from  AFR  57-1,  7 
October  1988. 
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The  final  document  discussed  in  AFR  57-1  is  the  Depot  Support  Requirements  Document, 
or  DSRD,  which  is  complementary  to  the  SORD.  It  describes  the  plans  and  requirements  for 
providing  depot  maintenance  and  material  support  to  the  system  described  in  the  SORD. 

Four  groups  are  involved  in  the  defined  requirements  process:  the  Operating, 
Implementing,  Supporting,  and  Participating  Commands. 


•  The  Operating  Command  is,  as  the  name  implies,  the  command  responsible  for  operating 

a  system,  subsystem  or  item  of  equipment. 

•  The  Implementing  Command  is  the  command  designated  by  the  Air  Force  Acquisition 

Executive  to  manage  the  acquisition  program. 

•  The  Supporting  Command  is  the  command  providing  the  logistics  support  and  managing 

the  program  after  transfer  from  the  Implementing  Command. 

•  The  Participating  Command  is  a  command,  or  agency,  advisory  to  the  program  manager 

and  active  in  the  development  of  the  weapon  system.  The  Supporting  Command  is  in 

fact  also  a  Participating  Command. 

With  the  groups  and  the  documentation  defined,  AFR  57-1  describes,  in  a  high-level 
manner,  the  process  by  which  operational  requirements  are  determined  and  defined. 

This  defined  requirements  process  is  not,  however,  as  efficient  as  possible,  particularly 
with  respect  to  the  overall  life  cycle  acquisition  of  the  weapon  system.  The  myriad  of  documents 
produced  by  the  process  (Figure  4,  [Stanley  and  Birkler,  1986])  contain  inadequate  and  often 
conflicting  requirements.10  Balancing  the  requirements  in  these  documents  is  not  easy.  No  single 
Air  Force  organization  can  balance: 

( 1 )  technical  factors  regarding  the  system, 

(2)  operational  factors  regarding  the  system  intended  use,  and 

(3)  institutional  factors  regarding  policies  and  procedures. 

Documentation  is  currently  fragmented  across  many  sources; 
requirements  are  inconsistent  from  one  document  to  another,  and  it 
is  extremely  difficult  to  correlate  key  operational,  contractual,  and 
test  requirements  fStanley  and  Birkler,  1986]. 


10See  Appendix  B  for  definition  of  each  document  name  contained  in  Figure  4  and  later  in  Figure  6. 
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Figure  4.  Documents  Produced  by  Acquisition  Process 

The  regulation  also  defines  what  the  operating,  implementing,  supporting,  and 
participating  commands  are  relative  to  the  weapon  system  acquisition  life  cycle.  The  combined 
efforts  of  these  involved  commands  determine  the  operational  requirements  for  modified  or  new 
weapon  systems  necessary  to  meet  evolving  mission  needs.  As  these  operational  requirements  are 
defined  and  evolve  over  time  the  SON,  SORD,  and  DSRD  documents  that  propose  the 
requirements  and  potential  solutions  are  created  and,  more  importantly,  evolve. 

Detailed  in  these  three  documents  are  not  only  the  mission  requirements  but  also  such 
support  functional  areas  as: 

•  Availability, 

•  Maintainability, 

•  Reliability, 

•  Logistics  Supportability, 

•  Basing  Infrastructure, 

•  Manpower,  Personnel,  and  Training  (MPT), 

•  Human  Factors/Engineering. 

The  involved  commands  must  consider  potential  system  solutions  to  meet  and  sustain  the 
operational  objectives.  An  essential  element  of  their  efforts  is  consideration  of  the  various  support 
functional  options  in  terms  of  operational  criteria,  trade-offs  within  the  functional  area,  and  trade¬ 
offs  between  the  functional  areas  and  the  mission  requirements. 
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The  knowledge  required  for  these  considerations  is  based  on  experience  with  current 
operational  systems.  Thus,  the  involved  commands  rely  on  experts  involved  in  similar  system 
development,  or  they  rely  on  the  adequacy  of  their  historical  databases  and  subsequent  analyses  to 
produce  the  necessary  criteria  (e.g.,  figures  of  merit,  measures  of  merit,  quantitative  operational 
criteria).  Additional  knowledge  comes  from  various  standards,  guidelines,  and  lessons  learned. 
The  key  point  is  that  a  wide  range  of  data  is  available,  and  should  be  made  available  to  the 
personnel  involved  in  the  requirements  process. 

Just  as  important  as  accessing  the  data  to  develop  the  necessary  criteria  is  using  the  data 
effectively  to  define  the  operational  requirements.  Understanding  the  overall  requirements  process, 
from  need  identification  to  the  ultimate  fielding  of  a  system,  is  a  prerequisite  for  anyone  involved  in 
the  acquisition  process.  However,  such  an  understanding  doesn't  prepare  an  acquisition 
professional  for  the  task  of  determining,  for  instance,  the  supportability  criteria  necessary  to  ensure 
the  final  operational  suitability  of  a  new  weapon  system  platform.  But  the  effective  determination 
of  these  supportability  criteria  is  crucial  to  the  ultimate  success  of  the  system  acquisition  effort 

Anyone  looking  back  at  the  late  1980s,  early  1990s  (and  beyond,  we  hope)  will  surely 
characterize  the  period  as  one  of  change.  Acquisition  streamlining  and  acquisition  reform,  a  long¬ 
standing  topic,  are  currently  very  important  efforts  producing  many  changes.11  These  recent 
changes  in  defense  acquisition  have  resulted  in  changes  to  the  foundation  documents  in  the 
acquisition  process,  among  those  DoDD  5000.1  and  DoD  5000.2-M,  "Defense  Acquisition 
Management  Documentation  and  Reports"  dated  15  August  1990.  As  changes  to  these  documents 
ripple  through  the  regulatory  guidance,  with  the  resulting  changes  in  procedures,  there  will  likely 
be  fundamental  changes  to  the  specific  steps  and  documents  required  by  the  requirements  process. 
For  instance,  DoD  5000.2-M  adds  a  new  baseline,  The  Concept  Baseline,  approved  at  Milestone  I 
and  applicable  to  the  Demonstration/Validation  phase  of  the  project  Such  a  baseline  places  a 
premium  on  the  quality  of  the  requirements  definition  and  analysis  aspects  during  the  concept 
exploration  efforts. 

While  these  changes  occur,  system  acquisition  personnel  will  continue  to  determine 
requirements  for  new  or  modified  systems,  conduct  tradeoffs  among  system  characteristics,  and 
manage  development  and  acquisition  efforts.  Tools  and  techniques  will  change  while  the 
fundamental  purpose  of  the  entire  process  remains  essentially  the  same.  The  remainder  of  this 
section  examines  current  tools  and  techniques  helpful  in  accomplishing  that  purpose  of  successful 
acquisition  efforts.  Since  the  purpose  of  this  entire  research  effort  is  to  enhance  the  requirements 
process,  these  tools  and  techniques  are  mapped  (in  Figure  5)  to  the  requirements,  perspectives,  and 


1  'Further  details  can  be  found  in  the  Packard  Commission  report,  the  Defense  Management  Review,  or  in 
numerous  Program  Manager  articles. 
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aspects  previously  defined.  While  each  check  or  cross  mark  is  not  explicitly  explained,  the 
indicated  correlations  help  understand  the  role  of  the  tool  or  the  technique  within  the  requirements 
process. 


IV.  APPLICATIONS 

Each  of  the  following  sections  describes  a  tool  or  technique  applicable  to  the  requirements 
process.  Each  is  listed  on  the  left  side  in  Figure  5  and  its  applicability  to  the  perspectives  and 
aspects  of  the  requirements  process  is  indicated  by  the  checks  and  crosses.  A  decision  support 
environment  that  accommodates  the  perspectives  and  aspects  of  the  requirements  process  while 
including  the  indicated  application «,  is  a  decision  support  environment  adequate  for  the  CE 
requirements  process. 


APPLICATIONS 

PERSPECTIVES 

ASPECTS 

Functional 

Hierarchical 

Buieacraiic 

Definition 

Analysis 

Management 

Need  identification 

v/ 

X 

X 

Template  requirements  tailoring 

v' 

v' 

X 

X 

Analysis  of  tradeoffs 

v' 

X 

X 

X 

Rationale  capture 

v/ 

X 

X 

X 

RCM 

v/ 

v/ 

X 

BCM 

v' 

X 

X 

Baseline  control 

v/ 

v' 

v/ 

X 

X 

X 

Requirements  traceability 

v/ 

v/ 

X 

X 

ECP  evaluation  tool 

v/ 

X 

X 

X 

Test  planning  and  management 

*/ 

v/ 

X 

X 

X 

Risk  analysis  tool 

*/ 

X 

X 

Audit  support  tool 

v' 

v/ 

X 

X 

Figure  5.  Mapping  Applications  to  Perspectives  and  Aspects 


Need  Identification 

Need  identification  refers  to  those  activities  involved  in  examining  operational  threat 
scenarios  and  determining  the  weapon  system  behavioral  characteristics  required  to  counter  the 
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operational  threat  scenario.  These  activities  can  occur  over  a  relatively  long  period  of  time.  For 
instance,  concept  direction  studies  lasting  1-2  years  fall  under  this  heading.  However  long  it 
requires,  the  end  result  of  the  need  identification  activity  is  a  characterization  of  the  operational 
need  (generally  system  level  or  operational  deployment  level)  necessary  to  meet  a  particular  threat 
scenario,  the  determinaaon  of  die  extent  10  which  current  capabilities  (i.e.,  systems)  cover  tire 
required  characteristics,  a  general  concept  of  the  deployed  system,  and  a  general  set  of  cost 
estimates  and  programmatic  documents  necessary  to  program  for  the  acquisition  and  development 
of  the  system.  Dependent  upon  the  concept  decided  upon,  the  eventual  program  may  be  either  new 
development  or  modification  of  an  existing  weapon  system  platform. 

Currently,  this  application  typically  falls  under  the  XR  staff  function,  usually  in  the 
acquisition  product  division,  who  then  work  closely  with  the  end  user  of  the  system.  The  products 
are  the  concept  studies  which  help  produce  the  SONs,  SORDs,  and  PMDs  necessary  to  commence 
with  the  program.  From  a  requirements  process  standpoint,  this  application  produces  the  highest 
level  requirements  that  the  final  end-use  item  (system)  must  satisfy.  This  is  the  first  stage  where 
the  system  "customer"  must  make  his  requirements  known.  Once  defined,  these  needs  and 
requirements  must  be  managed  for  the  remainder  of  the  project  to  track  the  evolution  and 
incorporation  of  the  requirements  into  the  final  system  configuration. 

The  above  definition  of  need  identification  can  expand  to  accommodate  activities 
throughout  the  product  life  cycle.  Need  identification  occurs  within  each  functional  discipline  as 
each  player  on  the  "design  team"  defines  what  is  needed  to  realize  the  end  system.  Each  player 
defines  his  pertinent  technical  environment,  to  borrow  a  concept  from  the  R&M  2000  Process 
pamphlet  For  instance,  it  is  extremely  important  to  address  logistics  support  during  the  earliest 
possible  stages  of  the  project  As  an  example,  consider  two  system  concepts,  one  of  which 
functions  within  the  current  Air  Force  basing  and  support  infrastructure,  the  second  requiring 
modifications  to  the  infrastructure.  Such  a  choice  has  very  different  cost  and  schedule  impacts. 
Failure  to  consider  these  issues  early  might  lead  to  definition  of  operational  requirements  to  meet  a 
system  concept  with  too  large  a  price  tag  to  be  feasible.  Such  definitional  activity  continues  as  the 
weapon  system  design  is  further  refined  and  detailed.  At  each  stage  of  definition,  new 
requirements  are  defined  based  upon  previously  defined  needs  and  requirements. 

Thus,  while  need  identification  is  typically  an  initial  planning  activity,  the  activities 
associated  with  the  identification  process  are  found  throughout  acquisition  and  development. 

Template  Requirements  Tailoring 

From  the  time  an  initial  need  is  identified  until  final  design  characteristics  are  defined  for 
component  fabrication,  the  requirements  process  relies  on  the  past  experiences  of  the  personnel 
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involved  in  the  project.  This  experience  is  used  to  examine  the  current  needs  and  requirements, 
and  from  those,  to  further  derive  a  set  of  requirements.  In  fact  AFR  57-1  acknowledges  past 
experience  as  the  primary  means  of  determining  SORD  and  DSRD  requirements.  This  past 
experience  takes  many  forms,  such  as  personal  experience,  lessons  learned,  guidelines,  or 
standards  developed  to  capture  individual  experts'  experience  and  knowledge.  This  experience  is 
applied  within  each  functional  area  and  iteratively  reapplied  as  design  detail  increases  through  the 
system  design  process. 

Whatever  form  this  experience  comes  in,  it  is  a  template  requiring  tailoring  to  the  design 
task  at  hand.  This  template  may  be  the  expert's  mental  image  of  the  system  based  on  the  defined 
requirements.  The  template  may  also  be  lists  extracted  from  the  guidelines  and  standards. 
Template  tailoring  is  a  crucial  step  in  the  requirements  process,  not  only  to  sufficiently  define  all 
the  pertinent  requirements  for  the  system,  but  also  to  explicitly  examine  each  requirement  against 
other  system  requirements.  The  understanding  gained  through  the  analysis  of  each  requirement 
with  respect  to  other  system  requirements,  and  the  definition  of  these  interactions  serve  to  delineate 
a  system  into  the  minimal  set  of  requirements  necessary  to  meet  a  specific  need. 

Within  the  acquisition  community,  tailoring  of  a  standard  is  already  a  required  process.  A 
standard  is  a  template.  Requiring  compliance  with  the  entire  standard  is  usually  excessive,  costly, 
and  inefficient.  The  DoD  recognizes  this,  and  regulations  require  tailoring.  Just  as  an  acquisition 
officer  explicitly  considers  each  requirement  of  the  standard  for  applicability  to  the  project,  so  must 
a  functional  expert  tailor  his  internal  knowledge  base  and  apply  that  tailored  knowledge  to  the 
current  project. 


Design  is  inherently  a  sequence  of  tradeoffs.  Design  has  also  been  characterized  as  merely 
a  decision  process  [Mistree  and  Muster,  1990].  From  the  time  various  options  are  examined  to 
counter  an  operational  scenario  until  a  system  is  fielded,  the  design  and  development  effort  requires 
tradeoffs  among  the  requirements  for  the  weapon  system.  The  earlier  these  tradeoffs  are 
accomplished,  while  maintaining  requirement  fidelity,  the  greater  the  potential  for  life  cycle 
savings. 

CE  embraces  the  multifunctional  approach  to  design.  The  product  and  the  processes 
required  to  produce  and  support  the  product  are  developed  in  unison.  The  most  successful 
approach  is  with  multifunctional  design  teams  comprising  members  from  the  various  functional 
areas  affecting  the  design.  This  team  approach  requires  extra  effort  and  extra  discipline  to  reap  the 
rewards  of  a  better  design  later  in  the  design  process. 


The  team  must  address  requirements  from  a  multidisciplined  point  of  view.  Each 
functional  representative  defines  system  requirements  necessary  to  improve  the  overall  design.  As 
these  requirements  are  defined,  the  interrelationships,  or  correlations,  among  other  requirements 
are  determined.  This  determination  requires  discipline  and  some  extra  effort,  but  must  be  done  to 
adequately  determine  the  impact  a  particular  requirement  has  on  the  overall  system.  This  takes 
time,  not  only  when  each  requirement  is  initially  defined,  but  as  each  requirement  is  refined  with 
greater  design  detail. 

This  determination  effort  provides  a  means  for  effectively  and  efficiently  conducting 
tradeoffs  among  design  parameters  (i.e.,  requirements).  A  proposed  parameter  change  can  be 
analyzed  with  respect  to  system  performance  and  impacts  to  other  system  parameters  and  support 
requirements.  Conversely,  changes  to  specific  system  performance  characteristics  can  be  analyzed 
with  respect  to  impacts  on  defined  system-level  requirements.  The  capability  produces  more 
complete  and  thorough  analyses  of  design  tradeoffs,  particularly  as  those  tradeoffs  apply  to  the 
tailoring  of  requirements  as  discussed  in  the  previous  section. 

Rationale  Capture 

Modifications  and  retrofits  to  fielded  systems  are  an  inevitable  part  of  the  weapon  system 
life  cycle.  The  causes  of  these  changes  fall  into  two  broad  categories:  correction  of  design  flaws 
or  oversights,  and  changes  to  missions  or  required  capabilities.  The  CE  initiative  has  a  goal  to 
decrease  the  costs  and  number  of  these  life  cycle  support  actions.  However,  this  CE  goal 
necessarily  applies  only  to  those  modifications  and  retrofits  due  to  design  flaws  (i.e,  poor  location 
for  maintenance  access,  incorrect  human  factoring,  part  repositioning  for  increased  reliability). 
Changes  to  mission  and  system  end  use  cause  the  other  set  of  changes,  and  since  these  changes  are 
nearly  impossible  to  predict  beforehand,  prevent  the  total  elimination  of  all  system  changes.  We 
can  however  ease  the  modification  process  by  providing  the  re-designers  with  the  capability  to 
understand  the  design  intent  of  the  original  designer  involved  in  the  design  determination  and 
tradeoff  process.  This  is  the  concept  of  rationale  capture. 

Long  after  the  original  design  team  has  moved  on,  the  redesign  team  needs  answers  to  such 
questions  as: 

•  Why  was  a  particular  operating  characteristic  required? 

•  Why  was  a  particular  concept  selected? 

•  Why  were  the  particular  subsystem  location  decisions  made? 

•  What  were  the  results  of  the  trade  studies  performed? 

Access  to  knowledge  of  previous  design  decisions  allow: 
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•  Redesign  to  proceed  by  reducing  the  need,  or  easing  the  process  of,  reverse  engineering. 

•  A  cost  impact  assessment  applied  to  the  original  (and  final)  design  decision. 

•  A  training  environment  for  newly  assigned  personnel. 

•  Development  of  a  more  effective  lessons-leamed  process. 

Rationale  capture  enhances  original  requirements  processing.  Rather  than  relying  on  an 
expert's  past  experience,  personnel  involved  in  the  requirements  process  draw  upon  past 
experience  captured  as  design  rationale.  Designers  thus  intelligently  apply  functional 
characteristics  to  the  evolving  design,  using  the  rationale  database  during  the  definition  and 
analysis  aspects  of  the  requirements  process.  More  importantly,  this  rationale  database  provides 
justification  to  management  for  the  various  design  decisions  as  well  as  a  legacy  of  sorts  on  the 
management  of  the  evolving  design. 

Requirements  Correlation  Matrix  (RCM) 

AFR  57-1  includes  the  RCM  as  a  required  attachment  to  the  SORD.  The  purpose  of  the 
RCM  is  to  provide  an  audit  trail  on  the  evolving  nature  of  the  SON  and  SORD  requirements,  and  a 
traceability  of  the  requirements  in  the  SORD  back  to  the  requirements  in  the  SON. 

The  RCM  is  primarily  a  management  tool  since  the  changes  tracked  are  at  a  high  level  of 
design.  While  the  RCM  does  provide  assistance  in  the  functional  perspective,  such  assistance  is 
again  at  a  very  general,  system  level  of  the  design.  It  is  however  applicable  to  correlating  user 
requirements  as  contained  in  the  SON  and  SORD  to  test  requirements  and  specifications. 

Baseline  Correlation  Matrix  (BCM) 

One  tool  proposed  by  Stanley  and  Birkler  [1986]  is  the  BCM.  Figure  6  depicts  its  role  in 
the  acquisition  process  with  respect  to  the  myriad  of  documents  described  in  Figure  4. 

The  role  of  the  BCM  is  to  correlate  requirements  contained  in  the  program  documentation 
and  specifications.  Too  often  requirements  provided  in  one  document  conflict  with  those  provided 
in  another.  The  program  manager  must  eventually  resolve  the  conflict;  however  it  is  more  efficient 
to  avoid  the  conflict  altogether. 

Conceptually,  a  system  requirement  is  contained  in  the  BCM.  As  that  requirement  is 
embedded  in  program  documentation,  a  relationship  is  established  between  the  requirement  and  the 
documentation  entry.  This  is  a  one-to-many  relationship  (one  requirement,  many  documents  and 
entries).  Thus,  consistency  is  established  among  the  documents.  Furthermore,  as  these 
requirements  evolve,  becoming  more  definitive  over  time,  the  BCM  ensures  consistency  through 
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the  specification  levels  (hierarchical  perspective)  and  within  the  functional  areas  (functional 
perspective). 

The  BCM  provides  the  program  manager  a  mechanism  to  ensure  consistency  of 
requirements  within  the  program,  program  documentation,  program  baselines,  and  program  test 
phases,  thus  avoiding  potential  conflicts. 


Figure  6.  Role  of  Baseline  Correlation  Matrix  (BCM) 


Baseline  Control 


Configuration  management  (CM)  has  three  main  functions,  all  associated  with  baselines: 

•  Configuration  identification, 

•  Configuration  control, 

•  Configuration  status  accounting. 
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As  a  discipline,  CM  is  well  defined  for  hardware  and  getting  better  defined  for  software. 
As  a  support  function  to  the  program  manager,  CM  is  absolutely  critical,  but  unfortunately  too 
often  neglected.  With  pending  changes  to  the  acquisition  process,  CM  faces  increased  challenges 
as  yet  another  baseline  is  proposed,  the  concept  baseline. 

Baselines  are  established  as  development  management  control  points.  The  baselines  serve 
to  document  the  current,  approved  configuration  of  the  system  and  provide  a  starting  point  from 
which  to  control  changes  and  the  change  process  with  respect  to  that  approved  configuration. 

Such  documentation  and  control  provide  management  insight  into  the  acquisition  and  development 
process.  From  a  government  standpoint,  there  are  essentially  four  baselines: 

•  concept, 

•  functional, 

•  allocated,  and 

•  production  (or  developmental). 

These  can  roughly  correspond  to  the  accepted  SON,  Type  A  specification.  Type  B 
specification,  and  Type  C  specification,  respectively.  Although  this  correspondence  is  sure  to 
cause  immediate  controversy,  and  raise  exceptions,  the  correspondence  serves  to  show  that 
government  manages  baselines  at  discrete  points  within  the  acquisition  and  design  process. 
Industry  is  tasked  with  building  the  system  to  meet  the  required  functional  specifications.  Industry 
must  deliver  the  end  item  and  the  specifications  describing  that  end  item.  Thus,  industry  must 
manage  their  baselines  in  a  more  dynamic  fashion  as  the  design  evolves  over  time,  yet  incorporate 
within  that  dynamic  control  process,  those  times  associated  with  government  defined  review 
points. 

In  terms  of  the  requirements  process,  government  needs  insight  into  the  specific 
requirements  comprising  each  baseline,  specifically,  insight  into  how  the  functional  requirements 
are  determined  and  decomposed  through  the  design  process  and  documented  in  the  formal 
management  baselines.  This  requires  management  of  the  requirements,  particularly  as  changes  to 
the  various  baselines  occur.  An  audit  trail  of  changes  to  the  baseline  provides  management  insight 
into  the  design  while  providing  definitional  and  analytical  support  to  government  personnel 
managing  the  development  and  acquisition  effort.  Baseline  control,  as  a  concept,  is  very  closely 
related  to  some  of  the  other  techniques  discussed  in  this  section  (e.g.,  BCM,  Requirements 
Traceability,  ECP  Evaluation).  The  point  made  here  is  that  baseline  control  is  a  distinct  and 
important  function  with  respect  to  program  management  and  the  overall  requirements  process. 
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Requirements  Traceability 


Requirements  traceability  is  the  explicit  establishment  of  relational  links  among  the 
requirements  of  a  system.  These  links  establish  dependency  relationships  among  requirements 
across  functional  disciplines  and  through  the  design  decomposition  process.  A  waterfall 
decomposition  process  as  depicted  in  Figure  13  is  very  idealistic.  Such  a  pure  hierarchical 
decomposition  of  independent  links  is  nearly  impossible  in  practice.  Real  weapon  system  designs 
are  actually  a  complex  set  of  interrelationships  and  decision  points.  However,  Figure  13  can  be 
used  to  show,  generally,  how  each  level  of  requirements  ties  back  to  higher  level,  and  ties  forward 
to  lower  level  requirements.  The  jump  in  complexity  comes  when  the  linking  takes  place  among 
functional  reauirements  and  through  multiple  layers  of  design. 

Traceability  provides  the  capability  to  tie  requirements  back  to  the  operational  threat.  The 
level  to  which  the  defined  requirements  satisfy  the  defined  need  gives  an  indication  of  anticipated 
customer  satisfaction  with  the  weapon  system.  Further,  changes  to  design  parameters  can  be 
analyzed  with  respect  to  impacts  to  the  original  need.  Design  parameters  that  are  not  directly  traced 
back  to  an  original  need  might  be  targets  for  deletion  or  require  further  analysis  and  definition. 

Traceability,  in  conjunction  with  the  BCM  tool,  determines  how  requirements  are 
embedded  with  system  documentation  and  baselines.  For  instance,  a  requirement  contained  in  a 
SON  can  be  traced  through  each  level  of  specification  through  to  the  test  step,  or  test  sequences, 
that  exercise  the  system  to  verify  satisfaction  of  the  need. 

Cost  impact  relationships  for  each  requirement  can  be  established.  Cost  estimating  during 
early  phases  of  design  is  not  an  exact  science,  although  it  is  often  mistaken  to  be  exact  Various 
cost  models  exist  for  hardware  and  software  systems  but  typically  cost  estimates  are  based  on 
previous  experience  with  similar  systems.  If  actual  cost  data  can  be  traced  back  through 
requirements,  and  allocated  to  the  high  level  quantifiable  (and  non-quantifiable)  weapon  system 
characteristics,  better  cost  estimating  relationships  (CERs)  can  be  established.  These  CERs  are 
beneficial,  not  only  for  new,  similar  developments,  but  also  for  modification  efforts  on  the  weapon 
system. 

The  desire  to  establish  such  a  complex  network  of  relational  links  among  requirements  is 
not  new.  The  technological  capability  to  accomplish  traceability  is  now  available,  and  a  matrix- 
based  data  structure  seems  the  most  desirable.  The  remaining  tools  and  techniques  rely  quite 
heavily  on  traceability  as  the  enabling  capability. 
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ECP  Evaluation  Tool 


The  Engineering  Change  Proposal  (ECP)  is  the  program  management  tool  to  propose, 
review,  approve,  and  implement  engineering  design  changes.  ECPs  are  an  important  part  of 
acquisition  management  and  weapon  system  development  Traceability  capabilities  enhance 
aspects  of  ECP  processing. 

As  ECPs  are  proposed,  impacts  to  various  requirements  are  examined.  This  examination 
includes  impacts  to  functional  requirements,  support  requirements,  and  cost  and  schedule  impacts 
due  to  the  change. 

As  ECPs  are  implemented,  baselines  change.  Such  changes  can  get  quite  complicated. 
Knowledge  of  all  change  impacts  and  affected  requirements  ease  the  change  process  by  ensuring 
completeness  of  the  change  review.  This  same  knowledge,  available  due  to  requirements 
traceability,  later  enhances  baseline  control  tracking  and  configuration  status  accounting. 

Finally,  ECP  cost  impacts  can  be  allocated  among  the  requirements  affected  by  the  change. 
Such  allocation,  again  via  the  traceability  tool,  enhances  cost  accounting  and  later  development  of 
more  effective  CERs. 


Test  Planning  and  Management 

The  basic  purpose  of  testing  is  to  verify  the  proposed  system  works  as  intended  and  as 
designed,  in  both  a  test  and  an  operational  environment.  Thus,  each  portion  of  a  test  should 
correlate  to  specific  requirements  for  the  system.  If  such  a  correlation  can't  be  established,  the  test 
step  is  wasted,  or  unnecessary.  Conversely,  if  a  requirement  has  no  corresponding  test,  the 
requirement  isn't  being  verified. 

If  Test  and  Evaluation  Master  Plan  (TEMP)  requirements  are  linked  into  the  weapon 
system  requirements,  via  the  BCM  and  traceability  tools,  TEMP  specifics  can  be  correlated  back  to 
specific  requirements  for  the  system.  Again,  this  correlation  ensures  proper  test  coverage. 

Once  the  test  is  conducted,  the  test  results  can  be  analyzed  with  respect  to  the  affected 
design  parameters  supporting  the  requirements.  One  immediate  benefit  is  to  develop  an  impact  list 
to  track  causes  and  fixes  for  failed  tests.  This  capability  enhances  test  management  efforts. 

Risk  Analysis  Tool 

Program  managers  place  their  emphasis  on  risk  areas  within  the  development  and 
acquisition  effort.  Risk  areas  can  be  defined  as: 

•  high  cost  areas, 

•  technological  uncertainty, 
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•  critical  impact  areas, 

•  schedule-critical  portions  of  the  program. 

Managers  need  insight  into  risk  areas  of  the  urogram.  They  need  answers  to  "what  if' 
questions  with  respect  to  cost  problems,  budgetary  fluctuations,  technological  shortfalls,  schedule 
slippages  and  so  forth.  It  is  therefore  desirable  to  have  the  ability  to  generate  complete  impact 
assessments  based  on  particular  risk  areas.  Specifying  a  requirement,  or  set  of  requirements,  as 
"risky"  provides  the  ability  to  assess  relative  impacts  due  to  the  requirement  This  then  provides 
enhanced  risk  management  capabilities  to  the  program  manager. 

Audit  Support  Tool 

As  baselines  are  established  and  managed,  the  system  becomes  a  reality.  What  was  once 
merely  a  concept  in  the  mind  of  the  user  is  now  a  piece  of  hardware  ready  for  operational  use.  The 
end  system  has  one  essential  purpose:  satisfy  the  end  user.  All  other  purposes  are  secondary. 

The  end  user  is  satisfied  (at  least  in  theory)  when  the  system  contains  all  the  functionality 
requested,  does  so  in  a  manner  acceptable  to  the  user,  and  demonstrates  operational  capability  over 
time. 

Audits  provide  a  confidence  check  that  the  system  will  satisfy  the  user.  The  Functional 
Configuration  Audit  (FCA)  verifies  all  the  functional  requirements  of  the  system  are  in  fact 
designed  into  the  system.  The  Physical  Configuration  Audit  (PCA)  verifies  the  system 
specifications  accurately  and  adequately  define  the  as-built  configuration  of  the  system. 

These  audits  ensure  the  conceptual  baseline  maps  to  the  final  production  baseline,  through 
the  intermediate  functional  and  allocated  baselines.  If  such  a  mapping  cannot  be  established,  the 
final  system  has  shortfalls.  An  audit  support  tool  provides  a  means  of  explicitly  detailing  the 
mapping  among  and  between  baseline  requirements  and  can  be  used  as  an  aid  in  accomplishing 
both  the  FCA  and  the  PCA.  This  mapping  ensures  that  the  functional  requirements  completely 
map  from  the  SON  through  the  baselines.  Conversely,  it  identifies  requirements  that  aren't 
satisfied  and  the  impacts  these  shortcomings  produce.  While  not  intended  to  eliminate  the  audits, 
such  an  audit  tool  wi’l  enhance  efforts  during  the  conduct  of  the  audits. 

Decision  Support  Environment 

The  purpose  of  the  preceding  discussions  was  to  motivate  the  need  for  a  DSS  environment 
that  fits  into  and  enhances  the  CE  requirements  process.  Some  of  the  tools  and  techniques 
discussed  are  particularly  applicable  to  a  decision  support  environment  implementation  using 
matrices.  Quality  Function  Deployment  (QFD)  is  one  technique  providing  the  required  discipline 
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and  focus  to  help  improve  the  requirements  process.  QFD  also  employs  a  matrix  presentation 
scheme.  As  a  paradigm  for  integration  of  the  tools  and  techniques  into  a  matrix-based  DSS 
environment,  QFD  provides  a  data  structuring  and  presentation  scheme  for  displaying  complex 
relationships.  Thus,  as  both  a  quality  engineering  technology  for  design  and  as  an  underlying 
paradigm  for  decision  support,  QFD  offers  potential  solutions  to  meet  the  CE  challenge  of  a  better 
requirements  process.  The  next  section  introduces  the  QFD  structure,  technique,  and  some  of  the 
philosophy  underlying  the  technique.  The  purpose  is  not  to  provide  a  QFD  primer,  but  rather  to 
provide  enough  background  and  basic  understanding  of  the  technique  and  its  graphical  devices  that 
the  reader  will  immediately  recognize  the  QFD  opportunity. 


V.  QUALITY  FUNCTION  DEPLOYMENT 
Organizational  Deployment  of  Quality 

The  objective  of  any  CE  design  and  development  effort  i ;  customer  satisfaction.  As  in  any 
quality-based  effort,  CE  requires  organizational  commitment  particularly  since  many  functional 
areas  and  management  levels  are  involved  in  the  design  and  development  effort.  A  popular  term  is 
“deployment”  of  quality  through  the  organization.  In  CE,  as  in  TQM.  there  are  two  organizational 
dimensions  of  quality  necessary  for  quality  product  development  These  cm  be  referred  to  as  the 
vertical  and  the  horizontal  dimensions  of  quality  [Sullivan,  1989]. 

The  vertical  dimension  is  intrauisciplinary.  For  instance,  within  manufacturing,  personnel 
are  concerned  with  conformance  to  manufacturing  specifications.  Optiir  'zation  of  the  product 
characteristic'  is  with  respect  to  manufacturing.  So  in  the  vertical  dimension,  design 
considerations  concern  just  the  given  functional  area. 

The  horizontal  dimension  addresses  interdiscipline  concerns.  For  instance,  how  does  a 
design  change  for  reliability  affect  manufacturing  concerns.  Design  decisions  consider  impacts 
across,  or  independent  of,  the  various  functional  areas.  Sullivan  characterizes  tins  horizontal 
dimension  as  the  "Voice  of  the  Customer"  since  design  considerations  are  system-wide  and 
typically  based  on  meeting  particular  requirements  for  the  system. 

Figure  7  from  Sullivan  depicts  how  such  an  organization  would  function  and  some  of  the 
tools  enabling  the  quality  deployment  effort.  Though  not  addressed  in  depth  in  this  paper,  a  large 
number  of  organizations,  particularly  in  Japan,  are  using  QFD  as  a  strategic  planning  tool.  The 
purpose  of  such  efforts  is  naturally  to  create  an  organization  focused  on  qt  ’lity.  By  examining  the 
quality  efforts  across  the  vertical  and  horizontal  dimensions  of  the  organization,  the  quality 
planning  effort  is  more  comprehensive. 
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This  paper  focuses  instead  on  the  use  of  QFD  as  a  quality  design  method.  QFD  promotes 
deployment  of  quality  across  functional  boundaries  within  the  product  design  effort.  It  is  a  method 
comprising  various  tools  and  techniques  to  translate  customer  requirements  into  increasingly 
detailed  design  requirements  to  ultimately  embed  the  customer  requirements  within  product 
characteristics. 


Figure  7:  Quality  Deployment  in  Organization 


What  is  QFD? 

But  what  is  QFD?  There  are  basically  two  approaches  to  QFD.  The  first  approach,  the 
Akao  approach  as  depicted  in  Bob  King’s  text.  Better  Designs  in  Half  the  Time  treats  QFD  as  a 
methodology  employing  a  matrix  of  quality  charts  (a  matrix  of  matrices).  These  matrix-based 
charts  document  the  design  process.  King  emphasizes  that  the  real  power  of  the  QFD 
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methodology  is  not  necessarily  in  completing  the  matrices,  but  rather  gaining  the  knowledge  and 
understanding  of  the  system  through  the  process  of  completing  the  charts  [King,  1989]. 

A  second  approach  to  QFD,  elaborated  in  Hauser  and  Clausing  [1988],  is  called  the  House 
of  Quality  (HoQ).12  In  effect  the  HoQ  approach  is  a  small  piece  of  the  methodology  described  by 
King.  This  paper  uses  the  HoQ  approach  [Hauser  and  Clausing,  1988;  Schubert,  1988  &  1989a 
&  1989b;  Sullivan,  1986  &  1988  &  1989]  primarily  because  the  HoQ  approach  brings  more 
potential  benefits  to  a  Decision  Support  System  (DSS)  environment  for  requirements  than  does  the 
King  approach.  While  King’s  approach  is  applicable  to  DSS  implementation,  the  HoQ  approach 
provides  potential  capabilities  for  requirements  determination,  requirements  traceability,  and 
rationale  capture;  critical  elements  of  the  weapon  system  design  and  acquisition  process  discussed 
in  Section  IV.  The  HoQ  approach  also  facilitates  the  deployment  of  quality  concept  thus  involving 
the  entire  organization.  As  Hauser  and  Clausing  [1988]  point  out: 

The  foundation  of  the  house  of  quality  is  the  belief  that  products 
should  be  designed  to  reflect  customers'  desires  and  tastes  -  so 
marketing  people,  design  engineers,  and  manufacturing  staff  must 
work  closely  together  from  the  time  a  product  is  first  conceived. 

Schubert  describes  the  HoQ  in  his  papers,  presenting  QFD  as  a  framework  for 
accomplishing  the  various  elements  of  systems  engineering.  QFD  is  actually  a  driving  force  in 
design,  the  framework  from  which  various  design  tools  and  design  elements  can  be  evoked.  In 
fact  Schubert  sees  systems  engineering  pervading  the  QFD  technique  with  QFD  focusing  on  the 
customer  requirements  primarily  while  the  engineering  requirements  become  secondary. 
According  to  Schubert  [1989a]: 

QFD  is  a  method  of  'mapping'  the  elements,  events,  and  activities 
that  are  necessary  throughout  the  development  process  to  achieve 
customer  satisfaction.  It  is  a  technique  oriented  approach  using 
surveys,  reviews,  analyses,  relationship  matrices,  and  robust  design 
all  centered  on  the  theme  of  translating  the  'Voice  of  the  Customer1 
into  the  items  that  are  measurable,  actionable,  and  potentially  capable 
of  improvement. 

History  of  QFD 

Before  describing  the  "how"  of  QFD,  it  is  useful  to  examine  some  of  the  QFD  history. 
QFD13  was  introduced  to  Ford  in  1984  as  a  result  of  findings  from  a  1983  study  mission  to 

'^Referred  to  as  the  Fukahara  House  of  Quality  approach  but  also  employs  the  Macabe  approach  of  using  a 
set  of  four  matrices  to  depict  the  four  phases  of  design:  product  planning,  parts  deployment,  process  planning,  and 
the  production  plans  stage. 

'•^Summarized  from  Hauser  and  Clausing,  1988,  Schubert,  1989a  and  Schubert,  1989b. 
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Japan.  The  technique  really  caught  the  public  eye  in  a  1988  Harvard  Business  Review  (HBR) 
article  by  Hauser  and  Clausing.  By  the  time  of  the  HBR  article,  two  companies,  GOAL/QPC14 
and  AST.15  were  actively  teaching  the  technique.  Historically,  QFD  originated  at  the  Mitsubishi 
Kobe  shipyards  in  1972.  There,  Dr.  Shigeru  Mizuno  of  the  Tokyo  Institute  of  Technology  was 
working  and  developed  "quality  tables."  These  tables  eventually  evolved  into  QFD. 

However,  there  is  little  reference  regarding  the  early  QFD  work,  and  this  has  created  some 
confusion.  During  the  late  1960s  and  early  1970s,  at  least  four  publications,  authored  or  co- 
authored  by  Dr.  John  N.  Warfield,  were  published  that  directly  relate  to  the  QFD  concepts.  In 
particular  is  a  1972  article  entitled,  "Unified  Program  Planning."16  To  briefly  explain,  the  Unified 
Program  Planning  (UPP)  technique  uses  trees  and  matrices  as  a  graphical  means  of  displaying  the 
linkages  between  various  program  planning  steps.  To  understand  the  complex,  highly  interrelated 
nature  of  design  steps,  such  visual  tools  are  necessary  to  accurately  and  neatly  convey  the  complex 
information  inherent  within  the  systems  engineering  sequence  of  steps.  Among  the  major  linkages 
defined  are  the: 

•  relationship  between  planned  activities  and  program  objectives, 

•  interaction  between  the  planned  activities  and  program  constraints,  and 

•  measurement  system  required  for  relating  the  progress  on  the  activities  to  the  attainment 
of  the  objectives. 

Hill  and  Warfield's  [1972]  paper  limited  the  discussion  to  program  planning  but  noted  the 
applicability  of  the  technique  to  other  phases  of  design.  Familiarity  with  QFD  and  the  UPP 
technique  highlights  the  similarities  and  differences  among  the  two  techniques.  Whether  either 
precedes  the  other  remains  a  topic  of  discussion,  although  recent  activities  have  sought  to  bring  the 
two  techniques  together  for  the  sake  of  CE.  Furthermore,  why  QFD  caught  on  while  UPP  didn’t 
is  unknown.  For  the  purpose  of  this  report,  a  discussion  of  the  "how"  of  QFD  suffices  to  depict 
the  technique  and  structure. 


A  Description  of  QFD 

QFD  starts  with  a  definition  of  “what”  the  customer  expects  from  the  system.  The  "whats" 
are  the  desired  system  behaviors  or  customer  attributes.  Developing  this  list  is  by  no  means  an 
easy  task.  Market  surveys,  group  opinion  gathering  techniques,  and  group  brainstorming 
processes  are  used.  These  techniques  need  to  identify  all  requirements.  Many  times  unspoken  or 


14GOAL/QPC  stands  for  the  Growth  Opportunity  Alliance  of  Lawrence,  Center  for  Quality,  Productivity, 
Competitiveness. 

15ASI  stands  for  American  Supplier  Institute 

16This  paper,  and  other  works  of  Warfield  are  referenced  in  Warfield  and  Kearney,  1989. 
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expected  requirements  are  missing  from  the  list.  The  customer  will  show  extreme  dissatisfaction  if 
these  requirements  are  not  in  the  end  product.  Once  captured,  the  relative  ranking,  or  importance, 
of  the  requirements  is  established.  This  ranking  is  also  a  difficult  task.  A  common  obstacle  is  the 
user’s  reluctance  to  prioritize  based  on  an  incorrect  perception  that  low-priority  needs  are  ignored. 
However,  these  relative  rankings  are  important  for  trade-off  design  studies.  Figure  8  is  an 
example  of  the  resulting  customer  requirements  list  and  ranking  block. 

The  next  step  is  to  determine  the  engineering  characteristics  (the  Hows)  necessary  to  meet 
the  customer  requirements.  Once  the  list  of  engineering  characteristics  is  accomplished  (Figure  9), 
the  design  team  determines  the  interrelationships  between  the  customer  requirements  and 
engineering  characteristics.  Figure  10  depicts  how  these  interrelationships  might  look.  A  matrix 
format  provides  a  much  cleaner,  easier  to  understand  graphical  display  (Figure  11)  than  is  depicted 
in  Figure  10.  This  cleaner  look  is  one  of  the  benefits  of  QFD. 


ENGINEERING 

CHARACTERISTICS 

/i/ 

REQUIREMENTS 

e— 

/ 

Figure  8.  Customer  Figure  9.  Engineering 

Requirements  (Whats)  Characteristics  (Hows) 


The  next  step  is  to  determine  interrelationships  among  the  engineering  characteristics. 
What  relative  effect  does  changing  one  engineering  characteristic  have  on  the  other  engineering 
characteristics?  These  interrelationships  are  symmetrical  in  nature  and  are  easily  displayed  using  a 
matrix  roof  such  as  shown  in  Figure  1 1  versus  using  a  separate,  complete  square  matrix. 
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CUSTOMER  ENGINEERING  ENGINEERING 

REQUIREMENTS  CHARACTERISTICS  CHARACTERISTICS 


Figure  1 1.  Matrix  of  Requirements  Interrelationships 


These  design  efforts  culminate  in  a  complete  House  of  Quality  as  depicted  in  Figure  12. 
Table  1  provides  additional  information  on  the  labeled  areas  of  Figure  12. 

Completing  one  house  doesn’t  produce  the  product.  At  each  step  of  the  design 
decomposition  process,  the  “hows”  of  each  House  (the  characteristics  across  the  top),  become  the 
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“whats”  for  the  next  level  decomposition.  Figure  13  shows  this  decomposition  process,  the 
waterfall  relationship.  The  important  points  are: 

•  a  multidisciplined  cadre  of  personnel  determines  the  requirements  by  addressing  life 
cycle  issues, 

•  communication  increases  among  design  team  members, 

•  matrices  of  relationships  promote  understanding  of  system  requirements,  provide 
relative  “sensitivities”  among  the  customer  requirements,  and  document  design 
knowledge, 

•  all  design  activities  trace  back  to  the  original  customer  requirements, 

•  better  requirements  improve  program  organization  and  focus,  and 

•  early  consideration  of  life  cycle  issues  means  less  change  later  in  the  design  process. 


Figure  12.  House  of  Quality  [Hauser  and  Clausing,  1988] 
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Table  1.  House  of  Quality  Elements 


ELEMENT  DESCRiptlON-  ~  ' 

1  Customer  Requirements  list  and  relative  prioritization 

2  Engineering  Characteristic  list 

3  Engineering  Characteristic  interrelationship  matrix  (roof) 

4  Customer  Requirements  -  Engineering  Characteristics 
_ interrelationships 

5  Customer  Preference  Chart  used  to  assess  relative  competitiveness 
in  a  market 

6  Technical  and  Cost  Assessment  used  to  allocate  resources  on 
elements  of  a  system  to  provide  the  most  benefit.  Uses  relative 

_ prioritization  and  engineering  difficulty 


Figure  13.  The  Waterfall  Decomposition  Process  [ReVelle,  1988] 


OFD  and  Systems  Engineering 

As  previously  reported  by  Schubert,  SE  pervades  QFD.  In  each  technique,  requirements 
are  thoroughly  defined  and  design  follows  a  hierarchical  decomposition  methodology.  However, 
there  are  some  fundamental  differences  [Schubert,  1989a]. 


(1)  SE  provides  inadequate  emphasis  on  understanding  the  interrelationships  among  the 
requirements  at  the  various  levels  of  design.  Thus,  a  great  deal  of  design  information  is  lost  in  the 
SE  approach  while  captured  in  the  QFD  approach. 

(2)  SE  focuses  efforts  on  the  product  while  QFD  emphasizes  the  design  and  production 
process.  As  a  technique  for  design  and  organizational  quality  deployment,  QFD  accommodates  all 
processes  required  to  produce  the  product. 

(3)  SE  is  generally  classified  as  the  “Voice  of  the  Engineer”  since  it  is  generally  the 
engineer  with  responsibility  for  the  requirements.  QFD  reflects  the  “Voice  of  the  Customer”  since 
the  original  customer  requirements  dictate  the  design  activity. 

(4)  Finally,  SE  produces  a  myriad  of  documents  covering  the  various  system 
requirements.  All  too  often,  there  is  ;nsufficient  correlation  among  these  documents.  This 
fragmentation  leads  to  inadequate  definition  of  some  requirements  and  conflicting  requirements 
between  documents  [Stanley  and  Birkler,  1986].  QFD’s  interrelated  matrices  depict  the  design 
process  and  provide  a  means  to  reconcile  conflicting  program  documentation,  a  point  expanded 
upon  in  Section  IV. 

Clearly,  this  is  not  a  thorough  discussion  of  QFD  nor  its  relationship  to  UPP.  This 
discussion  has  touched  upon  the  main  points  of  the  technique.  It  is  hoped  that  this  section  has 
provided  a  mental  image  of  how  such  a  matrix-based  technique  might  provide  a  paradigm  for  a 
decision  support  environment  accommodating  the  requirements  process  environment  and 
containing  tools  and  techniques  to  enhance  that  requirements  process  environment. 

VI.  CONCLUDING  REMARKS 

The  original  purpose  of  this  research  effort  was  to  investigate  the  potential  link  between 
QFD  and  CE.  CE  encompasses  the  entire  life  cycle  of  the  weapon  system,  from  concept 
development  to  operational  deployment  and  retirement.  QFD  is  a  very  methodical  approach  to 
design.  Broad-based  application  of  the  technique  to  an  entire  weapon  system  development  effort 
seems  self-defeating.  However,  selective  application  of  QFD-type  tools,  techniques,  and 
methodologies  are  promising  and  the  subject  of  related  research  [Pennell  and  Akin,  1990]. 

One  goal  of  CE  is  to  bring  design  considerations  to  bear  early  in  the  design  program.  For 
example,  it  is  hoped  that  consideration  of  the  manufacturing  processes  concurrently  with 
considerations  of  the  functional  design  will  avoid  manufacturing  problems  and  redesign  later  in  the 
program.  Much  of  the  precursor  work  in  DSS  dealt  with  technology  designed  to  support  such 
early  design  considerations.  The  selective  application  of  QFD-like  techniques  quickly  led  us  to 
examine  how  QFD  could  enhance  the  requirements  process  within  weapon  systems  acquisition. 
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Both  TQM  and  CE,  as  well  as  the  Air  Force,  recognize  how  important  it  is  to  build  and  deliver 
systems  the  customer  wants  and  will  use.  QFD  tries  to  capture  this  "Voice  of  the  Customer." 

The  problem  with  examining  the  requirements  process  is  trying  to  determine  what  piece  of 
the  process  to  work  on.  As  previously  discussed,  there  are  various  levels  of  management  involved 
in  the  process.  In  essence  the  entire  requirements  process  is  driven  from  the  top-down.  Policy 
and  general  procedures  emanate  from  headquarters  level.  Once  defined,  the  workers  at  the 
MAJCOM  and  SPO  level  figure  out  the  exact  methods  and  procedures  to  accomplish  the  job.  The 
approach  taken  in  this  research  was  to  define  the  requirements  process  in  a  very  general,  yet 
complete  manner,  and  this  definition  represents  the  perspectives  and  aspects  discussed  in  Section 
III.  Having  thus  defined  the  environment,  we  presented  a  set  of  tools  and  techniques  with 
capabilities  that  sufficiently  cover  the  environment  as  defined  by  the  perspectives  and  aspects. 

Such  coverage  provides  a  tool  set  that  workers  can  employ  to  accomplish  the  requirements  process 
relatively  independent  of  the  way  in  which  the  process  is  currently  defined  by  standards  and 
regulations. 

The  ultimate  objective  of  all  this  was  to  try  to  define  a  DSS  architecture  conducive  to  use  in 
the  requirements  process.  At  a  minimum  the  system  must  accommodate  the  current  requirements 
process  but,  additionally,  it  must  enhance  that  process.  As  mentioned,  much  work  was  done  at 
AJFHRL  in  the  area  of  decision  support  systems.  One  common  theme  was  the  desire  to  influence 
design,  in  a  positive  manner,  as  early  as  possible  in  the  weapon  system  life  cycle.  The  earliest 
phase  is  the  operational  need  determination  followed  by  the  evolutionary  process  of  weapon 
system  requirements  determination,  analysis,  and  management.  Our  envisioned  DSS  architecture 
must  accommodate  the  tools  and  techniques  presented  in  Section  IV  for  adequate  coverage  of  the 
requirements  process  and  we  see  the  QFD  paradigm  offering  potential  solutions. 

Observations 

The  literature  searches  and  discussions  yielded  a  set  of  observations  about  the  research 
opportunity  in  general. 

Observation  1 

Both  TQM  and  CE  place  tremendous  emphasis  on  properly  defining  who  the  customer  for 
a  product  (weapon  system)  really  is  and  what  the  customer  really  wants.  Policy  on  both  initiatives 
is  necessarily  vague  about  how  to  go  about  accomplishing  the  feat.  It  would  be  inappropriate  to 
dictate  how  to  implement  TQM  and/or  CE  considering  each  must  be  tailored  to  the  particular 
organization.  The  use  of  technology  to  assist  in  the  effort  is  necessary  but  not  sufficient  to 
accomplish  the  task.  Thus  any  DSS  tools  and  techniques  developed  and  integrated  to  accomplish 
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the  functions  envisioned  by  this  paper  must  adopt  the  philosophy  of  enhancing,  not  replacing-, 
human  performance  and  communication  among  design  team  members.  Such  a  system  will 
increase  the  discipline  within  the  requirements  process  and  help  meet  TQM  and  CE  goals  and 
objectives  at  all  levels  of  the  organization  hierarchy. 


Observation  2 

Recent  studies  and  papers  [Ferguson  and  Hertz,  1990;  Kent,  1989;  and  Miller,  1990]  have 
stressed  the  need  for  better  top-down  planning  in  the  area  of  operational  planning  and  acquisition  to 
support  the  operational  objectives.  We  found  traceability  of  requirements  was  an  enabling 
technique  for  most  of  the  tools  and  techniques  presented.  Furthermore,  traceability  is  an  enabling 
technique  to  improve  top-down  strategic  and  tactical  operational  planning.  The  ability  to  trace 
requirements  from  National  Security  Objectives  ultimately  to  fielded  hardware  to  satisfy  operational 
tasks  is  a  powerful  mechanism  for: 

•  budget  defense, 

•  program  justification, 

•  analysis  of  operational  capabilities, 

•  saving  time  and  resources  through  effective  force  deployment  and  planning. 

Observation  2 

The  use  of  expert  system  technology  will  play  a  major  role  in  any  DSS  development  effort. 
Such  systems  must  provide: 


•  functional  knowledge  of  present  system  capabilities, 

•  a  representation  scheme  to  depict  desired  system  capabilities  in  operational  settings, 

•  an  ability  to  identify  system  shortcomings  for  a  given  operational  scenario, 

•  knowledge  of  past  systems  and  lessons  learned, 

•  an  ability  to  bring  such  knowledge  to  bear  when  necessary, 

•  consistency  and  rationality  among  the  requirements  as  the  requirements  are  defined  and 
refined, 

•  data  presentation,  paper  and  computer-screen,  in  various  formats  from  single  data  sources. 


Observation  4 

As  designs  become  more  complex,  the  computer  and  computer  technology  will  play  an 
increasingly  critical  role  in  the  development  of  the  system.  In  light  of  the  Computer-Aided 
Acquisition  Logistics  Support  (CALS)  initiative  and  its  goal  of  paperless  acquisition  environments, 
systems  for  defining  and  managing  the  acquisition  effort  must  be  developed  that  can  interface  to 
and  assist  the  design-decision  support  environments.  Data  representation  schemes  must  be  capable 
of  storing  and  manipulating  data  for  design  influence,  for  management  oversight,  and  for 
analytical  tradeoffs  and  the  evolving  nature  of  the  design  requirements  and  constraints.  Network 
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trees  and  matrices  provide  effective  graphical  means  to  depict  complex  interactions,  such  as  those 
found  in  a  weapon  system  design.  DSS  technology  based  on  the  QFD  matrix  data  presentation 
paradigm  seems  well  suited  to  the  data  presentation  task. 

Issues  to  Address 

The  limited  scope  of  the  research  task  prevented  investigation  of  all  the  issues  and  concerns 
raised.  This  did  not  however  prevent  these  issues  and  concerns  from  coming  to  light.  Some  of 
these  are  discussed  below. 

User  Acceptance 

Any  time  DSS  technology  is  developed,  consideration  must  be  given  to  the  end-user 
environment,  and  in  particular  the  time  phasing  of  system  implementation.  Failure  to  consider 
such  things  often  results  in  user  disregard  for  the  system  (i.e.,  it  does  not  get  used).  Proposing 
and  developing  DSS  technology  to  assist  in  the  definition  and  management  of  requirements  for 
weapon  systems  is  a  new  field.  Though  bits  of  technology  have  been  employed  to  aid  the  process 
in  the  past,  for  the  most  part  the  process  is  paper  based.  Introducing  computer  technology  into 
such  an  environment  will  surely  meet  a  cool  to  lukewarm  reception.  Thus,  the  end-user 
environment  must  be  studied  and  understood  to  develop  systems  that  "fit"  into  the  environment  and 
the  existing  processes.  Such  a  fit  is  required  to  help  ensure  widespread  use  of  the  resulting  tools, 
methods,  and  technologies,  particularly  as  the  programs,  and  their  set  of  requirements,  transition 
into  program  management  during  the  development  and  production  phases. 

Group  Support  Technology 

CE  is  inherently  a  team  approach  to  design.  This  is  an  observation  found  throughout  the 
IDA  [Winner,  et  al.,  1988]  and  Pymatuning  [1988]  studies  and  supported  by  a  more  recent  EDA 
study  [Dierolf  and  Richter,  1990].  The  defined  process  for  requirements  contained  in  AFR  57-1 
implies  a  multifunctional  team  approach  to  the  definition  and  refinement  of  weapon  system  needs 
and  requirements.  Further,  since  the  weapon  system  requirements  process  involves  numerous 
organizations  located  around  the  globe,  communication  becomes  a  problem.  Functions  such  as 
brainstorming  and  concept  selection  play  a  vital  role  in  examining  options  to  meet  operational 
objectives  and  tasks.  The  accepted  staffing  of  requirements  documents  is  the  "shotgun"  approach; 
send  the  document  out  to  everyone  affected,  solicit  and  centrally  incorporate  their  feedback.  An 
effective  DSS  for  requirements  must,  at  some  point,  address  the  distributed  nature  of  the  DoD,  and 
business  in  general.  Recent  research  in  areas  such  as  Group  Decision  Support  Systems,  Computer 


42 


Supported  Cooperative  Work,  or  Global  Decision  Support  Systems  will  impact  future  DSS 
enhancements  to  the  requirements  process. 


Technological  Concerns 

Some  of  the  technological  concerns  were  alluded  to  in  the  above  observations.  O  Jier 
technological  issues  for  future  research  are: 

•  data  base  design  to  accommodate  the  complexity  of  the  data  and  the  relationships  among 

the  data, 

•  the  role  of  relational,  hierarchical  and  object-oriented  database  technology, 

•  the  level  of  design  detail  required  for  an  effective  system  and  how  these  requirements 

might  change  over  time  or  through  the  course  of  an  acquisition  effort, 

•  the  impact  advanced  simulation  environments  will  make  on  early  conceptualizations  of 

operational  requirements, 

•  documentation  tagging  and  management  schemes  to  manage  the  links  between 

requirements  and  the  documentation  containing  those  requirements, 

•  data  communication  technology  particularly  when  dealing  with  dispersed  teams, 

•  hypertext  and  Hypermedia  technology  for  navigating  through  the  set  of  design 

requirements,  and  the  information  associated  with  each  requirement, 

•  how  might  the  requirements  from  such  a  system  be  represented  so  that  they  become 

constraints  when  interfaced  to  a  design  decision  support  environment 

OFD  Uncertainty 

Even  though  this  research  proposed  QFD  as  a  paradigm  for  development  of  a  DSS  for  the 
requirements  process,  this  proposal  must  be  tempered  with  realistic  insights.  First,  the  QFD 
methodology  is  a  set  of  tools  and  techniques.  The  methodology  involves  very  detailed 
information  and  tremendous  discipline.  Although  this  effort  focuses  on  just  the  requirements 
process  aspect  of  design,  the  question  comes  up  concerning  QFD  for  the  entire  system.  Whether 
QFD  can  be  applied  to  an  entire  weapon  system  is  debatable  given  the  tremendous  amount  of  time 
and  effort  required  for  a  QFD  analysis.  Second,  there  is  the  question  of  what  portions  of  the  QFD 
methodology  should  be  applied  to  the  requirements  process.  In  many  instances,  a  DSS  based  on 
QFD  as  we  propose  is  actually  employing  just  the  graphical  aspects  of  the  methodology.  In  these 
instances,  the  term  QFD  should  not  even  be  used  since  it  causes  confusion.  Finally,  there  is  a 
mystique  about  QFD.  It  comes  from  Japan.  Nowadays,  that  automatically  brings  caution.  QFD 
requires  disciplined,  multifunctional  teamwork  not  typically  associated  with  America's  strengths. 

It  requires  heavy  upfront  involvement,  before  breadboarding,  before  mockups.  Again  this  is  not  a 
typical  aspect  of  American  design,  particularly  in  weapon  systems  design  and  development.  There 
are  however  real  benefits  from  QFD,  the  methodology,  and  the  graphical  devices.  Thus,  there  is 
uncertainty  if  a  scenario  such  as  depicted  in  Figure  14  is  even  possible.  What  is  implied  in  Figure 
14  is  that  QFD-based  tools  and  techniques  assist  the  mission  planners,  help  translate  needs  and 
requirements  to  weapon  system  requirements  and  characteristics.  These  requirements  and 
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characteristics  become  part  of  the  contractual  package  to  industry  who  must  then  translate  the 
contractual  requirements  into  design  features  embedded  in  the  delivered  system. 
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Figure  14.  Scenario  of  QFD  in  Requirements  Process 

Conclusions 


This  research  effort  arrived  at  a  set  of  conclusions  that  serve  to  guide  future  research  in  this 
DSS  for  Requirements  area. 


Conclusion  1 

One  way  to  achieve  the  TQM  and  CE  goals  of  improved  acquisition  efforts  (i.e.,  more 
capability,  less  cost,  less  time),  is  to  start  the  acquisition  effort  off  right.  This  means  improve  the 
requirements  process.  This  improvement  must  come  from  the  overall  requirements  process 
structure,  and  such  issues  are  being  addressed.  The  improvement  must  also  come  from  within  the 
infrastructure  with  tools  and  techniques  to  improve  and  enhance  the  efforts  of  the  individuals 
working  within  the  process. 


Conclusion  2 

The  graphical  devices,  as  well  as  many  of  the  tools  and  techniques,  of  QFD  can  be 
embedded  within  a  DSS  and  help  provide  capabilities  to  improve  and  enhance  the  definition, 
analysis,  and  management  of  weapon  systems  needs  and  requirements. 
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Conclusion  3 

The  requirements  process  is  essentially  i  top-down  driven  process.  The  structure  of  the 
process  is  defined  in  DoD  Instructions  and  in  Service  Regulations.  Within  that  structure,  the  needs 
and  requirements  ultimately  emanate  from  National  Security  Objectives  and  should  thus  have 
explicitly  defined  relationships  back  to  that  level.  Withir  the  acquisition  effort,  the  system  design 
effort  responds  to  high-level  guidance  contained  in  such  documents  as  the  SON  and  the  Program 
Management  Directive  (PMD).  Even  though  the  process  is  defined  and  functions  in  a  top-down 
manner,  tools  and  techniques  must  be  developed  from  the  bottom-up,  targeting  as  users  the 
individuals  defining  the  operational  tasks,  defining  the  equipment  and  capabilities  to  accomplish  the 
task,  and  possessing  the  past  experience  and  knowledge  necessary  to  adequately  define  the  weapon 
system. 

Conclusion.  4 

Expert  system  technology  can  play  a  key  role  in  capturing  past  experience  and  bringing  that 
experience  to  bear  in  application-specific  cases  where  a  need  or  requirement  must  be  fuiuier  refined 
and  traded-off  against  other  system  requirements  or  needs.  Expert  systems  can  be  employed  to 
ensure  consistency  among  the  requirements  as  well  as  completeness  in  the  definition  process. 

These  systems  can  promote  rapid  tradeoffs  among  competing  design  requirements  and  contain 
algorithms  that  help  "optimize"  the  design  alternative  under  consideration.  Finally,  the  system 
automates  the  more  mundane,  but  necessary,  tasks  such  as  documentation  generation  and 
maintenance  and  tailoring  of  applicable  standards. 
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DTIC#:  ADA210937 

Calkins,  Dale  E.,  et  al.,  Institute  for  Defense  Analyses,  IDA  P-2151,  May  1989 

Meta-Design  --  An  Approach  to  the  Development  of  Design  Methodologies 
DTIC  #:  AD  E501  228 

Rogan,  J.  E.  and  William  E.  Cralley,  Institute  for  Defense  Analyses,  IDA  P-2152, 

January  1990 

Management  of  Risk  and  Uncertainty  in  Product  Development  Processes 
DTIC#:  AD  A211  196 

Tse,  Edison  and  William  E.  Cralley,  Institute  for  Defense  Analyses,  IDA  P-2153, 

June  1989 

Managing  Engineering  Design  Information 
DTIC  #: 

Fulton,  R.  E.,  Chou  Pin-Yeh,  Karen  J.  Richter,  Institute  for  Defense  Analyses, 

IDA  P-2154,  October  1989 
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A  Survey  of  Research  Methods  to  Study  Design 
DTIC  #:  AD  A21 1  213 

Brei,  M.L.,  David  A.  Dierolf,  Karen  J.  Richter,  Institute  for  Defense  Analyses, 

IDA  P-2155,  June  1989 

Computer  Support  for  Conducting  Supportability  Trade-offs  in  a  Team  Setting 
DTTC#:  ADE501  219 

Cralley,  William  E.,  David  A.  Dierolf,  Karen  J.  Richter,  Institute  for  Defense 
Analyses,  EDA  P-2313,  January  1990 

Concurrent  Engineering  Teams 
DTIC#:  TBD 

Dierolf,  David  A,  Karen  J.  Richter,  Institute  for  Defense  Analyses,  IDA  P-2516,  September  1990 

Development  of  the  University  of  Maryland  RAMCAD  for  Electronic  Systems 
DTIC#: 

Richter,  Karen  J.,  Institute  for  Defense  Analyses,  IDA  M-425,  October  1988 
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APPENDIX  B 


DEFINITION  OF  ACQUISITION  DOCUMENTS 
FROM  FIGURES  4  AND  6 


SDDM 

Secretary  of  Defense  Decision  Memoranda 

PMD 

Program  Management  Directive 

DCP 

Decision  Coordinating  Paper 

IPS 

Integrated  Program  Summary  (now  obsolete) 

SCP 

System  Concept  Paper 

JMSNS 

Justification  for  Major  System  New  Start 

SON 

Statement  of  Operational  Need 

(P)SOC 

Preliminary  System  Operational  Concept 

Opnl  Concept 

Operational  Concept 

Maint  Concept 

Maintenance  Concept/Maintenance  Planning 

ILSP 

Integrated  Logistics  Support  Plan 

Mil  Stds 

Military  Standards 

SOW 

Statement  of  Work 

DT&E 

Developmental  Test  and  Evaluation 

TEMP 

Test  and  Evaluation  Master  Plan 

OT&E 

Operational  Test  and  Evaluation 
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